Nytro Game Engine Development Blog

An assembly object in Nytro terms, is a scene node that holds a hierarchy of scene nodes or slots for scene nodes. So for example you have a tank with wheels attached to a body, a turret that can rotate, and a gun attached on that turret. Also for the muzzle flash particle system you have a slot on the gun, at its end. All this complex hierarchy is defined in a *.assembly.xml file format. Here we have a video example:

<assembly>
	<slots>
		<slot class="Model" name="body" file="models/body/body.model.xml" translation="1.870190,0.018445,-0.069976" pivot="0.000000,0.000000,0.000000" rotation="0.000000,0.000000,0.000000,0.000000" scale="1.000000,1.000000,1.000000" >
			<slots>
				<slot class="Model" name="turret" file="models/turret/turret.model.xml" translation="5.246300,14.022100,0.408924" pivot="0.000000,0.000000,0.000000" rotation="4.111712,0.000000,1.000000,0.000000" scale="1.000000,1.000000,1.000000" >
					<slots>
						<slot class="Model" name="gun" file="models/gun/gun.model.xml" translation="-10.754400,5.583590,-0.214642" pivot="-10.926900,-1.618770,-0.000000" rotation="90.000000,1.000000,0.000000,0.000000" scale="1.000000,1.000000,1.000000" />
					</slots>
				</slot>
				<slot class="Model" name="wheel_front_l" file="models/wheel_front_l/wheel_front_l.model.xml" translation="-18.369900,6.254620,22.929800" pivot="0.000000,-2.952030,0.000000" rotation="90.047203,0.999177,0.028690,0.028690" scale="1.000000,1.000000,1.000000" />
				<slot class="Model" name="wheel_front_r" file="models/wheel_front_r/wheel_front_r.model.xml" translation="-18.369900,6.254620,-22.176701" pivot="0.000000,-2.952030,0.000000" rotation="90.000000,1.000000,0.000000,0.000000" scale="1.000000,1.000000,1.000000" />
				<slot class="Model" name="wheel_back_r" file="models/wheel_back_r/wheel_back_r.model.xml" translation="19.323000,6.254620,-22.176701" pivot="0.000000,-2.952030,0.000000" rotation="90.000000,1.000000,0.000000,0.000000" scale="1.000000,1.000000,1.000000" />
				<slot class="Model" name="wheel_back_l" file="models/wheel_back_l/wheel_back_l.model.xml" translation="19.323000,6.254620,22.929800" pivot="0.000000,-2.952030,0.000000" rotation="90.000000,1.000000,0.000000,0.000000" scale="1.000000,1.000000,1.000000" />
			</slots>
		</slot>
	</slots>
</assembly>

Worked on the exporter side, to get data from DCC tools (Maya, MAX, XSI, whatever) to the engine. The main workflow goes like this (tho will be improved): you model your thing in the 3D package of your choice, export the scene/object as a COLLADA (.DAE) file, using the package’s COLLADA exporter (some DCC tools have their own, some can be extended with free COLLADA exporters like ColladaMAX, ColladaMaya, XSI has its Crosswalk thingie; after you have the *.DAE file, you will run The NAC (Nytro Asset Compiler) from command line, like this (it also has options switches not shown here): nac “d:\where my dae at\some.dae” “d:\some\gamedata\output here”, this will generate, depending on COLLADA file contents and given NAC options, a *.mesh or more, or *.material.xml, *.model.xml, *.anim for objects and/or skeletons, and so on. That’s all, from there you setup and use the resulting optimized binary files how you wish.

Materials had a little, yet major modification done to them, now in a .material.xml file you can have a <subMaterials> tag and have <material> children sub-materials, so when you apply a material to some mesh, it will apply submaterials onto the submeshes of that mesh. Example for a model with a mesh containing 3 submeshes:

crate.material.xml:
 
<material>
    <subMaterials>
        <material name="frontSide" shader="materials/shaders/generic.shader.xml" shaderPreset="generic">
            <textures>
                <texture file="textures/some1.png"/>
                <texture file="textures/some2_normal.png"/>
            </textures>
        </material>
        <material name="leftSideOfCrate" shader="materials/shaders/ice.shader.xml">
            <textures>
                <texture file="textures/some2.png"/>
                <texture file="textures/some2_normal.png"/>
            </textures>
	</material>
        <material name="topWaterThing" shader="materials/shaders/water.shader.xml" shaderPreset="pool">
            <textures>
                <texture file="textures/some3.png"/>
                <texture file="textures/some3_normal.png"/>
            </textures>
        </material>
    </subMaterials>
</material>
 
crate.model.xml:
 
<model>
    <lods maxDistance="100">
        <lod mesh="meshes/box.mesh" distance="0">
            <subMesh material="models/crate/crate.material.xml" subMaterial="0" />
            <subMesh material="models/crate/crate.material.xml" subMaterial="1" />
            <subMesh material="models/crate/crate.material.xml" subMaterial="2" />
        </lod>
    </lods>
</model>

In the future I will add a tag to select a material for the entire LOD, so you dont specify a material, same material for each submesh, but the option to override a submesh material with other will remain of course.

Started on writing basic engine usage tutorials/examples, but I’m afraid this milestone for an alpha SDK for 25 dec. will not reach its completeness, but things are going nicely, rushing it would probably do more bad than good. As always, stay tuned.

Cropped some HLSL code and got up and running SSAO (Screen Space Ambient Occlusion – more details on how its done: http://www.gamerendering.com/category/lighting/ssao-lighting/ ).
The first pass in the scene: render depth information in a texture’s alpha channel and scene normals (World*View matrix transform) in the RGB channels, then use this information to render SSAO in a render target. It uses the normals and pixel depth to compute the occlusion between current pixel and several samples around that pixel, chosen by sampling texels from depth map around it, using a random normals texture (more on the page above).
Some SSAO screenies:

No SSAO

With SSAO, observe shadowing

Cleaned up the code a little bit, removed unnecessary hassle, and verified the code for leaks. The CRT debug function from VisualStudio are ok, but sometimes they give you a headache setting up the memory leak detection, I have tried Visual Leak Detector, free stuff, works pretty well, and it tells you the line number and source file also.
The editor is going on nicely, docking is working quite well and all the floating windows are in place now, waiting to be filled up with great tools .
Because of the time left, I will try to give away a pre-alpha release of the engine API, and a small example, before XMAS 2009 or something like that, so people see how easy is to work with Nytro, until then a good documentation and some simple tutorials must be written, lets hope I’ll make it , stay tuned!