Techdemo: Vegetation progress: Instancing on vegetation layers

March 7th, 2010

The vegetation system comes along quite nicely, there can be defined several layers of vegetation objects, for example trees, grass and rocks, no limit whatsoever. Each vegetation layer has 3 levels of detail for its objects, 3D model, 3D impostor and 2D billboard/impostor, the radius around camera and other many parameters are tweakable, so you can make engine profiles for low/medium/high machines, depending on power. The vegetation objects can swing in the wind, in the future the trees or other vegetation objects will be breakable, the problem is a little bit more complex, because it must switch off the instanced object and create a new dynamic/broken one in the scene, but its doable.

Here is a small tease of the terrain and vegetation (the assets are ugly though, no time for that now, only tech)

Vegetation objects

Vegetation objects

Techdemo: Vegetation rendering

February 23rd, 2010

I have opted for a database of terrain objects, generated positions/colors/scale for each instance from a distribution map and several tweakable parameters, outputs to some instance data file which can be loaded or later on streamed and instances being updated around the camera, when needed. The problem is to find the right instances around the camera radius from lets say 1 million objects (trees, grass patches,rocks,detail objects), of course you cannot search through all them, computing distances for each one, so I figured out that a quad tree will help it, assigning instance index lists to leaves, wrote a generic quad-tree class, which can take user specified callbacks to subdivide and query for data, so you can use it in any quad-tree-worthy feature you might have.

COLLADA deception

February 17th, 2010

“Wow! COLLADA is so great!” were my first words about COLLADA, after a brief research made :) . But devil is in the details. COLLADA is a nice format that can store everything, let me emphasize, everything. I have use it for quite some time, its good when you use the same DCC tool and the same exporter for DAE, but when that DAE comes from various DCC tools and also exporters, things get nasty, of course it can be an escuse for a lame importer, but still, the format is too loose for game development at least, and now I’m limited at exporting only the mesh data, skeletons get complicated a little, etc., so in a moment of “professional rage” I have started an open source game asset file format specification and its exporters for MAX, Maya and XSI, plus a simple import/load library, called .GSCENE , found at http://sourceforge.net/projects/gscene (work in progress of course).

If you dont believe me about COLLADA, then start using it, good luck :)

Techdemo: Grass in the wind

February 1st, 2010

The grass looks good, added layers of grass, basically the terrain can have 3 types of instanced things on it: grass (blades looking at camera, on a radius around the camera ), trees (they have special features, like LOD with impostors, physics, etc) objects ( like soda cans, broken branches, detail objects ), so you can have many layers of these objects on the terrain. More info soon. Posted a small work in progress video:

Techdemo: Terrain physics and grass

January 25th, 2010

The terrain has heightfield shapes attached to it so it collides with other objects, or the objects collide with it… Anyway, the terrain is around 20×20 km visible, but can be extended to even 250×250 km invisible/streamed from disk, because you simply add more terrain patches on the fly.

So we have the physics, a simple skybox which will evolve into a scattering solution, cubemap computed on CPU and used on a sphere as skysphere, Mie Rayleigh scattering.

The terrain texturing is now done with 4 diffuse textures, one detail normap map, but I will change it to use texture atlas for diffuse/normal/specular, this way I can have like 10 diffuse textures in one texture (stage), and same for normal and specular, and the splatting will be done in shader, we’ll have to test the performance of this approach, but it is quite appealing.

Next, after the terrain physics, I want to see some nice grass on the terrain, so the grass will be instanced on the terrain using a distribution map: Red will be used to paint grass, Green will be used to paint trees, Blue can be used to paint rocks, Alpha to paint detail objects like broken branches or soda cans.. Each channel can have its procedural parameters, like spacing, rotation,scaling,slope min/max. This system can be extended to use more than one map to generate stuff on the terrain, and you can just do something like: terrain->addDistributionChannel( someMap, CHANNEL_RED, someObjectInstancingInfo );

The grass in particular, will be culled around the camera, inside a radius, and it will fade away using alpha testing (not blending ), the grass will bend in the wind using shader driven motion, and I’ll think how I can add arbitrary forces like ship engines blowing down to the grass or helicopter’s blades. The grass blades will always face the camera, they will not be only vertically locked, actually that can be some flag for a specific channel, some sort of VERTICAL_BILLBOARDING flag.

Pictures/videos soon.

Started “Eternal 2″ – Nytro TechDemo Game

January 16th, 2010

Developing an engine, and a pretty generic engine its pretty hard and can lead you to a point where you dont know why you are developing that feature, will it be really used ? maybe not.. so I have decided to write a game in parallel with the engine development, Eternal 2, “sequel” of the first mini game wrote with Nytro, for some competition, it was a 1-week project, check the video here:

The game will show off flying vehicles, terrain vehicles, drones, landscape / vegetation, sky, and other small things. The development progress will be shown on this blog, on the Eternal2 game gategory. Wish me luck :) . More info on story, gameplay, soon.

Fixed pipeline mode goodbye, console commands & variables

January 14th, 2010

I had the rendering of text and UI elements, and also debug / schematic rendering based on the SetShader(NULL), which fell back on the fixed function pipeline of the driver/card, but this thing is gone in DX10 and beyond, so I said bye bye to FF, and added a new ‘basic’ shader that only can render unlit simple stuff, colored and textured/untextured primitives, now the engine is really full shader based.
The engine has a console with commands that can be registered in C++ and script code, and also it has a global variables system, which can be created dynamically or from the engine.setup.xml or from C++/script code, the variables are Variant objects holding any kind of data from numbers to strings (is there any more ? :) )

nytro::engine::setGlobalVariable( "yeah_someGlobalVar", 2.0f );
nytro::engine::setGlobalVariable( "someGlobalVar2", "HAHA!" );
nytro::engine::setGlobalVariable( "someGlobalVar3", 123 );
 
Variant val = nytro::engine::getGlobalVariable( "yeah_someGlobalVar", 2.0f /*default*/ );
or
float32 val = nytro::engine::getGlobalVariable( "yeah_someGlobalVar", 2.0f /*default*/ );

Assemblies – What are they ? What are theeeeeeey!!??

December 30th, 2009

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>

DCC tools exporter, materials and tutorials

December 23rd, 2009

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.

SSAO with scene normals

December 6th, 2009

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

No SSAO

With SSAO, observe shadowing

With SSAO, observe shadowing