IXSF -- The Irrlicht XML Scene Format

Robomaniac · Post by **Robomaniac** » Thu Feb 26, 2004 6:27 pm

I'm attempting to start a *hopefully* standard engine format for creating levels. My plan is to have a base editor, which you add meshes, and nodes in a scene. Basically, you would start with a blank scene. Then say, add a skybox, then a bsp level, then a tree or ammo pack. I've seen this done w/ ogre, and liked it. The file format would be based off of xml, and be held in a .ixsf file. If anyone would like to help me please pm, aim, e-mail, or post here. I'm going to need some help if i want to get this project off the ground.

Miwa · Post by **Miwa** » Thu Feb 26, 2004 8:43 pm

You might want to consider just embedding lua into your app, and using that to describe the scene.

I do that for my visualization app. The user just loads a selected lua file, and the lua file sets up the whole scene by calling all the irrlicht functions you'd call after parsing your own scene format file.

It's easy to add pre-render callbacks and all sorts of other things, once you go thru the effort of exposing irrlicht functions to your script.

To make things easier for end users, you could always make functions that take something like a mesh, and texture, and do all the calls that load it, and set the material props.

For example, here's a piece of example script:

Code: Select all

function main()
   
   guiEnv = CLU_Call("GuiGetGuiEnvironment", IrrDevice);
   driver = CLU_Call("VideoGetVideoDriver", IrrDevice);
   smgr = CLU_Call("SceneGetSceneManager", IrrDevice);

   text1 = CLU_Call("GuiAddStaticText", guiEnv, "text1", {TopLeft={x=10,y=10},BottomRight={x=300,y=30}},1,0);
   text2 = CLU_Call("GuiAddStaticText", guiEnv, "text2", {TopLeft={x=10,y=40},BottomRight={x=300,y=60}},1,0);

   camera = CLU_Call("SceneAddCameraSceneNodeStatic", smgr);
   CLU_Call("CameraSetFarValue", camera, 60000);
   CLU_Call("SceneSetActiveCamera", smgr, camera);
   CLU_Call("NodeSetPosition", camera, {x=100,y=50,z=-200});
   
   missile = CLU_Call("SceneGetMesh", smgr, "d:/terr1.ms3d");
   missile_pos = {x=0,y=0,z=0};
   missile_node = CLU_Call("SceneAddAnimatedMeshSceneNode", smgr, missile, 0, -1, missile_pos, {x=0,y=0,z=0}, {x=50,y=50,z=50});
   CLU_Call("NodeSetMaterialFlag", missile_node, 2, 0);
   CLU_Call("AnimatedMeshSceneNodeSetFrameLoop", missile_node, 0, 0);
   missile_tex = CLU_Call("VideoGetTexture", driver, "d:/board1.bmp");
   CLU_Call("NodeSetMaterialTexture", missile_node, 0, missile_tex);

end

saigumi · Post by **saigumi** » Thu Feb 26, 2004 9:45 pm

Also, leaving its extension as XML would save a lot of us a lot of hassle.

If it's an XML file, the XML extension works and saves some of us a lot of time on pre-setup. Like making or updating a new Document Class in Textpad for syntax highlighting and using xml verification tools that aren't configured to check files that don't have an xml extension.

Robomaniac · Post by **Robomaniac** » Thu Feb 26, 2004 10:07 pm

Yep, i was definately planning on keeping it xml, since thats all i really know how to program in terms or "scripting" like languages, plus, its easy to use w/ c, so that makes producing an editor easier too.

stoffe · Post by **stoffe** » Fri Feb 27, 2004 2:53 am

Miwa wrote:You might want to consider just embedding lua into your app, and using that to describe the scene.

I do that for my visualization app. The user just loads a selected lua file, and the lua file sets up the whole scene by calling all the irrlicht functions you'd call after parsing your own scene format file.

It's easy to add pre-render callbacks and all sorts of other things, once you go thru the effort of exposing irrlicht functions to your script.

To make things easier for end users, you could always make functions that take something like a mesh, and texture, and do all the calls that load it, and set the material props.

For example, here's a piece of example script:
Code: Select all
function main()
   
   guiEnv = CLU_Call("GuiGetGuiEnvironment", IrrDevice);
   driver = CLU_Call("VideoGetVideoDriver", IrrDevice);
   smgr = CLU_Call("SceneGetSceneManager", IrrDevice);

   text1 = CLU_Call("GuiAddStaticText", guiEnv, "text1", {TopLeft={x=10,y=10},BottomRight={x=300,y=30}},1,0);
   text2 = CLU_Call("GuiAddStaticText", guiEnv, "text2", {TopLeft={x=10,y=40},BottomRight={x=300,y=60}},1,0);

   camera = CLU_Call("SceneAddCameraSceneNodeStatic", smgr);
   CLU_Call("CameraSetFarValue", camera, 60000);
   CLU_Call("SceneSetActiveCamera", smgr, camera);
   CLU_Call("NodeSetPosition", camera, {x=100,y=50,z=-200});
   
   missile = CLU_Call("SceneGetMesh", smgr, "d:/terr1.ms3d");
   missile_pos = {x=0,y=0,z=0};
   missile_node = CLU_Call("SceneAddAnimatedMeshSceneNode", smgr, missile, 0, -1, missile_pos, {x=0,y=0,z=0}, {x=50,y=50,z=50});
   CLU_Call("NodeSetMaterialFlag", missile_node, 2, 0);
   CLU_Call("AnimatedMeshSceneNodeSetFrameLoop", missile_node, 0, 0);
   missile_tex = CLU_Call("VideoGetTexture", driver, "d:/board1.bmp");
   CLU_Call("NodeSetMaterialTexture", missile_node, 0, missile_tex);

end

A bit off-topic here (sorry!) but I have to ask, about lua: what does lua buy you, except from possibly less recompiles? From what I see in your example, it seems that what you get with lua is tons of added CLU_Call and a syntax that is *harder* to read than C++ (however that is possible...)

I've been experimenting with building a ruby module to control Irrlicht (not hard, just lots of work and need to nail the interface if it should be done, SWIG can't really handle it sadly), and the tests I've done with that results in cleaner, simpler code, no recompiles, etc. That, in my world, must be the whole point with adding scripting - it makes absolutely no sense if you lose that won compiletime in unreadable and verbose code.

Example:

Code: Select all

device = create_device DT_SOFTWARE, [600, 480], 16, false

device.window_caption = "Hello World! - Irrlicht Engine Demo"

driver = device.video_driver
smgr   = device.scene_manager
guienv = device.gui_environment

guienv.add_static_text("Hello World! This is the Irrlicht Software engine!", true, [10,10,200,30]);

mesh = smgr.get_mesh "media/sydney.md2" 
node = smgr.add_animated_mesh_scene_node(mesh);
smgr.add_camera_scene_node # TODO: args!!!

	while device.run do
		driver.begin_scene true, true, [0,100,100,100];

		smgr.draw_all;
		guienv.draw_all;

		driver.end_scene;
	end

The above was the ruby adaption of parts of the first tutorial, not really complete but you get the point. Apart from completing lots and lots of stuff, the next step would of course be to create convenient shortcuts for the common tasks, but then we are closer to a game engine or something (which is what I really want in the end

)

Have I completely missed something (I don't know lua), is that snippet not a good example or what? From what I hear. lots of people recommend lua, but right now I can't understand why.

Please note that I only want an explanation, not trying to trash anyone or anything.

powerpop · Post by **powerpop** » Fri Feb 27, 2004 4:43 am

Three Dimensional Markup Language

This is something I invented about five years ago when VRML came out and I couldnt deal with its brainlessness! Its an XML format for describing scenes - it will also be part of the Ping Game Framework. I thought about proposing it as a general scene layout format. Here is a sample of 3DML that includes some Simkin scripting on some of the nodes:

Code: Select all

<spot version="3.3"> 
<head> 
<title name="Flatland.com | Moola | Great Hall" />
<blockset href="http://spots.flatland.com/moola/blocksets/moola_doors.bset" />
<blockset href="http://spots.flatland.com/moola/blocksets/moola_flatsun.bset" />
<blockset href="http://spots.flatland.com/xuriel/blocksets/xuriel_greathall.bset" />
<blockset href="http://blocksets.flatland.com/flatsets/basic.bset" /> 
<map style="double" dimensions="(21,21,2)" /> 
<sky texture="@basic:clouds.gif" />
<orb brightness="100%" position="(0,0)" color="(255,255,128)" />
<ambient_light brightness="40%" />
<ambient_sound file="sounds/great_hall_theme.wav" />
</head> 

<body> 

<!-- THE MARBLE FLOOR, TRANSLUCENT TO SHOW "REFLECTED" SCENE -->
<create symbol=".," block="ground">
	<part name="*" texture="@xuriel_greathall:marbtile.jpg" translucency="20%" />
</create>

<!-- THE FLATLAND SUN -->
<create symbol="**" block="flatsun">
	<param movable="yes" />
	<part name="*" style="scaled" />
	<define>
		<scale_x>8.0</scale_x>
		<scale_y>8.0</scale_y>
		<scale_z>8.0</scale_z>
	</define>
</create>

<!-- THE FLATLAND SUN -->
<create symbol="*2" block="flatsun">
	<param movable="yes" />
	<part name="*" style="scaled" faces="2" />
	<define>
		<scale_x>8.0</scale_x>
		<scale_y>-8.0</scale_y>
		<scale_z>8.0</scale_z>
	</define>
</create>

<!-- THE GREAT HALL, TO BE SCALED -->
<create symbol="#1" block="greathall">
	<param movable="yes" />
	<define>
		<scale_x>21.0</scale_x>
		<scale_y>21.0</scale_y>
		<scale_z>21.0</scale_z>
	</define>
</create>

<!-- THE INVERTED GREAT HALL BLOCK, TO BE SCALED AND
	FLIPPED FOR REFLECTION IN MARBLE FLOOR -->
<create symbol="#2" block="greathall">
	<param movable="yes" />
	<part name="*" faces="2" />
	<define>
		<scale_x>21.0</scale_x>
		<scale_y>-21.0</scale_y>
		<scale_z>21.0</scale_z>
	</define>
</create>

<entrance name="default" location="(11,3,1)" angle="180.0" /> 
<entrance name="red" location="(11,3,1)" angle="180.0" />
<entrance name="blue" location="(11,19,1)" angle="0.0" />
<entrance name="wood" location="(19,12,1)" angle="270.0" />
<entrance name="white" location="(3,11,1)" angle="90.0" />

<!-- THE DOORS: OPENED/CLOSED AND REFLECTED -->

<create symbol="NO" block="doorsnorthopen">
	<param movable="yes" orient="180" />
	<part name="background" texture="../000001/images/thumbnail.jpg" />
	<exit href="../000001/index.3dml#red" trigger="step on, click on" />
</create>

<create symbol="no" block="doorsnorthopen">
	<param movable="yes" orient="180" />
	<part name="background" texture="../000001/images/thumbnail.jpg" />
	<part name="*" faces="2" />
	<define>
		<scale_x>1.0</scale_x>
		<scale_y>-1.0</scale_y>
		<scale_z>1.0</scale_z>
	</define>	
</create>

<create symbol="SO" block="doorssouthopen">
	<param movable="yes" orient="0" />
	<part name="background" texture="../000003/images/thumbnail.jpg" />
	<exit href="../000003/index.3dml#blue" trigger="step on, click on" />
</create>

<create symbol="so" block="doorssouthopen">
	<param movable="yes" orient="0" />
	<part name="*" faces="2" />
	<define>
		<scale_x>1.0</scale_x>
		<scale_y>-1.0</scale_y>
		<scale_z>1.0</scale_z>
	</define>	
	<part name="background" texture="../000003/images/thumbnail.jpg" />
</create>

<create symbol="EO" block="doorseastopen">
	<param movable="yes" orient="270" />
	<part name="background" texture="../000006/images/thumbnail.jpg" />
	<exit href="../000006/index.3dml#wood" trigger="step on, click on" />
</create>

<create symbol="eo" block="doorseastopen">
	<param movable="yes" orient="270" />
	<part name="*" faces="2" />
	<define>
		<scale_x>1.0</scale_x>
		<scale_y>-1.0</scale_y>
		<scale_z>1.0</scale_z>
	</define>	
	<part name="background" texture="../000006/images/thumbnail.jpg" />
</create>

<create symbol="WC" block="doorswestopen">
	<param movable="yes" orient="90" />
	<part name="background" texture="../000008/images/thumbnail.jpg" />
	<exit href="../000008/index.3dml#white" trigger="step on, click on" />
</create>

<create symbol="wc" block="doorswestopen">
	<param movable="yes" orient="90" />
	<part name="*" faces="2" />
	<define>
		<scale_x>1.0</scale_x>
		<scale_y>-1.0</scale_y>
		<scale_z>1.0</scale_z>
	</define>	
	<part name="background" texture="../000008/images/thumbnail.jpg" />
</create>

<!-- IMPORT THE SCALE FUNCTION -->
<import href="scripts/scaleblock.3dml" />

<!-- AT START, SCALE AND POSITION BLOCKS -->
<define>
	<function name="start">
		/* Get the block object */
		block = map.get_block("#1");
		scaleblock(block);
		block.location:y = 0;

		block = map.get_block("#2");
		scaleblock(block);
		block.location:y = 0;
		block.location:x = block.location:x - 256;

		block = map.get_block("**");
		scaleblock(block);
		block.location:y = 128;
		block.location:z = block.location:z - 256;
		//block.rotate_x(90);
		
		block = map.get_block("*2");
		scaleblock(block);
		block.location:y = -128;
		block.location:z = block.location:z - 256;
		block.location:x = block.location:x - 256;
		//block.rotate_x(-90);
		
		block = map.get_block("NO");
		block.location:y = 0;
		block.location:x = block.location:x - 128;
		block.location:z = block.location:z + 31;

		block = map.get_block("no");
		scaleblock(block);
		block.location:y = 0;
		block.location:x = block.location:x - 384;
		block.location:z = block.location:z + 31;

		block = map.get_block("SO");
		block.location:y = 0;
		block.location:x = block.location:x - 128;
		block.location:z = block.location:z - 256;

		block = map.get_block("so");
		scaleblock(block);
		block.location:y = 0;
		block.location:x = block.location:x - 384;
		block.location:z = block.location:z - 256;

		block = map.get_block("EO");
		block.location:y = 0;
		block.location:x = block.location:x + 31;
		block.location:z = block.location:z - 128;

		block = map.get_block("eo");
		scaleblock(block);
		block.location:y = 0;
		block.location:x = block.location:x - 225;
		block.location:z = block.location:z - 128;

		block = map.get_block("WC");
		block.location:y = 0;
		block.location:z = block.location:z - 128;

		block = map.get_block("wc");
		scaleblock(block);
		block.location:y = 0;
		block.location:x = block.location:x - 256;
		block.location:z = block.location:z - 128;
		
	</function>
</define>

<script trigger="timer" delay="0.01">
	block = map.get_block("**");
	block.rotate_y(1);
	block = map.get_block("*2");
	block.rotate_y(1);
</script>

<level number="1">  
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., ., .,
</level>  

<level number="2">  
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. NO no .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. ** *2 .. .. .. .. .. .. .. .. .. 
WC wc .. .. .. .. .. .. .. .. #1 #2 .. .. .. .. .. .. .. EO eo 
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. SO so .. .. .. .. .. .. .. ..
</level>

</body> 
</spot>

and a graphic of what it produces - the sun rotates by the way

the format needs some updating which is what i am trying to do with ping - the blocks are currently placed on a grid - i need to add the ability to place blocks at any position in a scene - the blocksets are sets of meshes - i added the ability to bring in any random mesh in ping as well as entire blocksets - there needs to be some rethinking of the head part of the file since there are some things there you want to be able to change in the middle of a game - like the skydome for instance

but overall i think XML is a great way to go - and i would love to see 3DML become more of a standard - so if people want to work with me on reshaping 3DML to be more generally useful i am all for it - i have 3dml.org and this effort can live there, become part of Ping.net and used in other projects![/img]

Miwa · Post by **Miwa** » Fri Feb 27, 2004 6:00 am

A bit off-topic here (sorry!) but I have to ask, about lua: what does lua buy you, except from possibly less recompiles? From what I see in your example, it seems that what you get with lua is tons of added CLU_Call and a syntax that is *harder* to read than C++ (however that is possible...)

Well, it gets you a number of things. Ease of prototyping is certainly one of them. It's much easier to just edit a line in a script, and reload the scene, than it is to recompile my entire app (which is quite large). I just drop everything in the scenemanager, and the guimanager, and just run a script to try changes.

My interface is very basic right now, so it's really ugly. I just did the minimum work possible to make it possible to use a script to describe a scene for a demo I have coming up. I'll clean up all the ugly interfaces by making helper functions or just make my own C->Lua bindings (I'm using CALua right now, which is why all the CLU_Call stuffs)

Longer term, if you are doing a complete game, you may want things like AI and object interaction to run independantly of the game engine, and thats where the real power comes in. Using co-routines, it's possible to code each entity to operate it's own little state machine. Almost all games these days use some sort of scripting engine to handle the content, and the game engine just exposes stuff to the script.

Lua is great because it's small, very fast, and designed to be embedded into other applications. It's not whitespace sensitive, so that kicks butt too. Lua 5.1 should have incremental garbage collection, and that should help tremendously with real-time applications (games count as real-time, as they have hard deadlines). My day job is creating software for real-time embedded systems.

The other nice thing about scripting, verses using .ini files, or parsing a xml file to store state information is it's just plain easier to write out state info by emitting code, that then calls your app when doing a load. I have a fancy config system in my app that allows the user to save all the window positions, and object states. It's much easier to recreate all that state by just having a script call the function that creates the state, than parse a file and deal with trying to decode the info and create state.

stoffe · Post by **stoffe** » Fri Feb 27, 2004 1:31 pm

I did understand all the benefits of scripts in general before

but what you basically are saying is that lua is well suited in terms of implementation (easy to embed/extend) and it is possible to clean up the syntax significantly? If so, gotcha - it was just that it looked like your example code made the code hard(er) to read and maintain, which I'm not sure I'd trade for compile times.

If the syntax can be cleaned up, tweaked and specialized (somewhat easily at least) then I understand better why people recommend lua, and I'll probably have a look at it too.

Thanks for taking the time!

buhatkj · Post by **buhatkj** » Fri Feb 27, 2004 6:14 pm

fmorg has a simplifies sort of XML level format.level have the following:
-level mesh
-any number of "spawnpoints"
-any number of static map objects(thaing that arent part of the main map mesh, but are re-useable map scenery, like trees or boulders)
-any number of NPC's(defined by another XML format i made)
-any number of items(also each defined by their own XML file)
-scaling, translation, and rotation values
-any number of dynamic lights
-any number of "triggers"(each of which would have it's own XML file)

this is pretty much only focused on the things one needs in an RPG level, but a lot of it makes sense in any 3d game...
i plan to do the scripting using tolua++ and each item, trigger, and player could have any number of script associated with them which would correspond to their different states(they each would have a finite state machine).

its not perfect and not NEARLY finished, but you ARE free to gank it if you wish!
http://fmorg.sf.net

oh and of course no 3d game is worth its salt without a good editor, which thanks to irrlicht's new gui features is in the works, (not much progress yet, but workin on it...)
-Ted

Robomaniac · Post by **Robomaniac** » Fri Feb 27, 2004 7:39 pm

Hm ... both seem to be viable options to modify. I like the .level format b/c it allows rot, scal, and trans, lights, spawn points, and triggers, while i like 3dml's way of defining entities, (havn't looked at .level yet, but it looks awesome. So, i think i might try to merge the two and create a 3dmlevel (:-P 3dmlevel he he, i crack myself up). I'm finally going home in an hour or so, so i will look at it more fully there.

buhatkj · Post by **buhatkj** » Fri Feb 27, 2004 7:56 pm

oops, actually that sorta a typo. i don't actually call them .level files, they are just .XML, but what is important is the way i format them. although, the idea does occur that i COULD call them .lvl or something of the like, would allow me to differentiate between the different formats of XML files i use...
like:
.lvl for levels
.plr for players
.itm for items
.tgr for triggers
.eft for effects
.mob for map objects
and then .cfg for game settings(graphics, sound volumes..the like...)

and they would all be just XML files, but the extension would help to differentiate them...
neat idea...
-Ted

stoffe · Post by **stoffe** » Sat Feb 28, 2004 3:47 pm

buhatkj wrote:oops, actually that sorta a typo. i don't actually call them .level files, they are just .XML, but what is important is the way i format them. although, the idea does occur that i COULD call them .lvl or something of the like, would allow me to differentiate between the different formats of XML files i use...
like:
.lvl for levels
.plr for players
.itm for items
.tgr for triggers
.eft for effects
.mob for map objects
and then .cfg for game settings(graphics, sound volumes..the like...)

and they would all be just XML files, but the extension would help to differentiate them...
neat idea...
-Ted

Put them in different directories instead, and keep the .xml extension - directories are a better way to sort stuff anyways, and you let editors and operating systems know you have xml files and nothing else.

buhatkj · Post by **buhatkj** » Sun Feb 29, 2004 7:34 am

does changing the extension screw up syntax highlighting? i guess that could be a reason, tradeoff i guess...
-ted

saigumi · Post by **saigumi** » Sun Feb 29, 2004 2:33 pm

Yes, changing the extensions means more work to get some applications to accept the format.

If you use TextPad, you'd have to add the extensions to your XML document class.

You wouldn't be able to quickly open them in IE or Mozilla as they would think that they are some other sort of file.

agrif · Post by **agrif** » Fri Mar 19, 2004 12:39 am

On the subject of XML loaders, since everyone else is saying an idea...

This is probably not the best way to do things, but...

For the game that I'm working on, the game engine uses an XML loader. But, unlike all the other loaders I've heard, it doesn't support the editing of scene node attributes. Basically, you do something like this:

Code: Select all

<scene name="SomeScene" contentdir="someDir">
    <mesh file="yay.obj">
        <texture file="tex.jpg"/>
    </mesh>
</scene>

Very simple, I know. This also parses for dynamic lights, skyboxes, animators, collision hulls, and supports inter-scene teleports.

but, the way to add things like NPCs, ammo pickups, or gigantic rotating energy sources that can warp space-time is to add a plugin in the form of a DLL. You load this plugin and say:

Code: Select all

<space_time_warp name="..." .../>

The form of the plugin DLL is just a class and a function. The check() function accepts the TiXmlElement that the parser is currently parsing, checks if it is the plugin type, and returns NULL or a pointer to the class in the DLL.

The classes in the plugins all inherit from ISceneNode and are kept in a std::vector, and can register themselves to update every n seconds, or register for events.

---

Anyway, that's the way I'm doing it. And if your wondering why you cant say the x,y,z values of a mesh, its because I export all of my meshes with global co-ordinates from the scene. It saves the time of positioning them from within the engine after export.

Its a flawed idea, I know, but I had to get all that out of me.

agrif

Irrlicht Engine

IXSF -- The Irrlicht XML Scene Format

IXSF -- The Irrlicht XML Scene Format

3dml

i have been doing XML level in a simplified sorta way...

typo...

Re: typo...

syntax highlighting...