Graphic engine and graphic technologies

[etheral walker]

will the mesh format be the default ogre one?

[klauss]

Yes, definitely.
Now that mesher works reliably well (ie - automated, unedited output really works, instead of just crashing Ogre), I'm thinking about still supporting BFXM/OBJ... but that's a longshot.

[zaydana]

I don't know the technicals in all this... but would it perhaps be a good idea to abandon bfxm/xmesh alltogether? It wouldn't be hard to swap over (automated conversion script, anyone?). If the new format is better, lets just leave the old ones.

[chuck_starchaser]

Klauss, any chance we could have a quick synopsis of what the new mesh format will be capable of? 2 issues are immediately at stake for me: One is animations. Can I have a landing gear foldout animation whereby when fully retracted most of the geometry goes away and only the cover remains? And can I change vertex colors as part of the animation so that the details of the gear become gradually illuminated as they come out of the dark interior?
The other is texturing: I'm hoping to be able to mix repeatable tiling textures and non-repeating global textures. The repeating texture I might use for just metal rust, armor plate seam lines, or other fine-grained stuff. The global texture would have burnt-in radiosity derivatives.
And an extra question: Does the Ogre mesh format include vertex shaders? I need some special animations I could use vertex shaders for, like helical cable that stretches...

[rewpparo]

Most of wxhat you describe is not actually in the mesh, but the material scripts. Mesh data only contains vertex, normals, and uv mapping. I'll take all the issues one by one.
1. landing gear retraction : You can do that, not in the mesh format, but with a tiny bit of coding. Put skeletal animation for the cover to make it open and close, and create a landing gear mesh that will move down. make it disappear if you wish when it's fully retracted.
2. landing gear shading effect : I never tested shadowing with Ogre, but Ogre does support self shadowing. I believe this is the effect you're looking for. just activate shadow casting on your ship, and shadow recieving on your landing gear leg. different shadowing techniques will give you different styles of gradual illumination.
3. multiple texture mapping : of course you can do that ! check Ogre samples, that's what landscapes are done with. just define a material with multiple texture layers, and scale them like this :

Code: Select all

material tiling
{
	technique
	{
		pass
		{
			texture_unit
			{
				scale 1
				texture texture1.png
			}
			texture_unit
			{
				scale 0.5
				texture texture2.png
			}
			texture_unit
			{
				scale 0.25
				texture texture3.png
			}
		}
	}
}

This is a basic example, you can do anything you want with that.

4. yes ogre supports vertex and pixel shaders in GLSL, CG and HLSL. both are defined in materials scripts, so you can change them at runtime.

[klauss]

For all those questions, it would be better to brows Ogre's wiki, mostly the Features list, and probably the Manual (most precisely, the section about material scripts).

Short answers:

• Animations: bone systems. Most of what you said, but I'm not sure about vertex colors
• Texturing: that and more... read the material scripts thing for full details.
• Shaders: yes. Both. Vertex and Fragment shaders.

[chuck_starchaser]

Okay, thanks guys. Now, I believe mesh animations were part of the bfxm format weren't they? So we'll need some mesh class that subsumes the Ogre mesh format and adds animation data? Or shouldn't that be degrees of freedom, actually? And might as well have it do mesh substitutions? Like replacing the landing gear by just a cover when it's fully closed? Also, for damage, we were thinking about having pieces of ship armor coming off and showing exposed ship internals. The ship internals aren't part of the mesh, though; but I was thinking, we could have generic ship internals that we can place behind ripped panels when needed. Can meshes be so modified? Does this relate to the mesh format at all? Possibly not, except that for any part of the armor that gets hit we could probably use knowing where to place the circumstantial internals, and having this info in the mesh...
Also, when a ship is on-deck and I climb the ladder to get into it, I need to see both the ship AND the cockpit. Call this one LOD -1, if you will. Only when the cockpit is open...

Been reading the features list.

# Flexible mesh data formats accepted, separation of the concepts of vertex buffers, index buffers, vertex declarations and buffer mappings
# Export from many modelling tools including Milkshape3D, 3D Studio Max, Maya, Blender and Wings3D
# Skeletal animation, including blending of multiple animations and variable bone weight skinning
# Biquadric Bezier patches for curved surfaces
# Progressive meshes (LOD)

Can one define per-vertex color? I'm asking because I was thinking of the possibility of using, for darker materials, the full RGB numerical range in the texture, but having it multiplied by vertex-interpolated color, by the videocard, at floating point precision. For radiosity baking, it would be much more efficient to store this info per-vertex, also; rather than using the glow texture (glow texture compresses much better without radiosity).

In fact, I suppose the vertex shader could also do some vertex color magic, for special effects like illuminating the back of a ship when you press afterburner, without having to use a light source for every engine exhaust; though this is unrelated to the mesh format... Except in the fact that I would need to flag which vertices are visible from the exhaust flame; otherwise vertexes hidden from it will be illuminated; and I wouldn't want to compute self-shadowing at run-time for it, when I can do that manually offline. We could use such flags also for indicating flashing lights, for instance: The vertex shader could use a boolean input throttling on/off times, and any vertexes flagged as flashers would have their glow component turned on or off accordingly.

So, I guess the question is, does the Ogre mesh format include the possibility of extra per-vertex info (RGB color; uchar radiosity, etc.) or boolean flags (illuminated by exhaust flame; flashing; etc.)?

Now, shaders are part of the material, you say. So, suppose I have a hydraulic cylinder between a fixed point in a mesh, and a point on an animated mesh, and I write a vertex shader that implements the way the piston-cylinder telescope and move as the animated mesh rotates. But now, do I have to declare my hydraulic as a special "material", in order to apply that vertex shader to it?

[rewpparo]

For ship damage, i'm working on something like this right now. Just make the hull entity invisible, and have another mesh with ship internals behind it.

For exhaust illumination, in general, it's a bad idea to do per vertex operations outside the GPU. CPU should be used for IA, physics and stuff, but not graphics.
Use a shader for this. For example a pixel shader multiplying the pixel colour by the dot product between normal and vector to the afterburner.

For the hydraulics cylinder, yes you have to define a material to get the vertex shader. However I'm not sure this is the right way to do it, you should use deformable physics. But I don't know much about this, except that it's very demanding in CPU.

You really should try Ogre out. get the sources, compile it, try the demos, and hack with them a bit. I'm sure you'll love it, it allow for very specific and cool looking effects, without much effort.

[etheral walker]

regarding mesh formats, there is already many exporters for ogre, so is it really needed to modify ogre mesh loader? I mean, most of known 3d packages have their own exporter. For the shading question, browse the forums, but there is already some tools for visual editing, and there is even an exporter for rendermonkey, a free shader designer from ATI

[chuck_starchaser]

For ship damage, i'm working on something like this right now. Just make the hull entity invisible, and have another mesh with ship internals behind it.

I think the idea I gave you is more efficient, though: Have just small pieces of ship internals that are put in there only when needed, and only behind the particular breach in the hull, rather than a whole big mesh of internals for the whole ship. A whole mesh of internals would also have to be ship-specific --i.e.: fit into a particular ship. If you do just pieces of internals and put them just under the holes, they can be reused for many ship types. And I'm not sure how you're planning to *place* the internals. I re-submit, there should be data IN the mesh for where internals should be placed, one location per group of polys, say.

For exhaust illumination, in general, it's a bad idea to do per vertex operations outside the GPU. CPU should be used for IA, physics and stuff, but not graphics.
Use a shader for this. For example a pixel shader multiplying the pixel colour by the dot product between normal and vector to the afterburner.

That's exactly what I was talking about. You misunderstood me. When I said "off line" I didn't mean the CPU, at run-time. I meant at design time. I never thught of using the CPU at all. Shader. Dot product. Exactly as you say. The problem is that only some parts of the ship are exposed to the exhaust flame. Others aren't, due to self-shadowing. But I want to avoid using Ogre's self shadowing for illumination by the exhaust. Using it for sunlight is enough. The location of the exhaust is fixed relative to the ship. In fact, I can tell just looking at the model which parts of the ship are exposed, and which parts aren't. So I just want to be able to flag those that are, *at ship-design time*, and for that flag to be in the mesh.

For the hydraulics cylinder, yes you have to define a material to get the vertex shader. However I'm not sure this is the right way to do it, you should use deformable physics. But I don't know much about this, except that it's very demanding in CPU.

No, no physics needed for that. It's only a graphical deformation; no forces required. I know how to do it in a vertex shader, in GLSL; I was just wondering if vertex shaders really needed materials to hook into. That's not very elegant, I must say. Vertex shaders are not naturally related to materials. Fragment shaders are, of course. Vertex shaders are mesh-specific and should live in meshes. But I realize the issue of variable passing interface matching between vertex and fragment shaders; however, that only implies a need for interface matching, rather hard-wiring. Defining an inter_shader_interface type, and a shader_pair class that can only be formed out of vertex and fragment shaders whose interfaces match. Something like that. I'm sorry if I sound critical, but I am a bit disappointed about this particular detail. A hydraulic is a hydraulic, whether it's made of steel, aluminium, or wood, for that matter. I think klauss and I had a more comprehensive scheme brewing, at one point, for organizing shaders. Pity... ^^

You really should try Ogre out. get the sources, compile it, try the demos, and hack with them a bit. I'm sure you'll love it, it allow for very specific and cool looking effects, without much effort.

Okay, I will; I've just been thinking more as a modeller than as a programmer, lately. My questions were more about how I get my model to do X *in the (new, Ogre-ized) Vegastrike engine*...

[klauss]

and there is even an exporter for rendermonkey, a free shader designer from ATI

Just a heads-up: I've used, and the exported shaders are a little messy. It's best to write the shaders in rendermonkey (for the nice previews), and then copy/paste into shader files and setup the thing manually.
Also, it's a very good idea to use rendermonkey to assign texture units to samplers... take a peek at the disassembly listing rm provides, and you'll see which sampler goes to which texture unit. It's important, because if you map things differently the instruction count could change and go above the limit.

Thing is... the rendermonkey exporter has a lot caveats, which usually result in Ogre crashing, so I've only used it for mapping samplers and getting previews, but everything else is better left as manual work.

[klauss]

Vertex shaders are not naturally related to materials. Fragment shaders are, of course. Vertex shaders are mesh-specific and should live in meshes. But I realize the issue of variable passing interface matching between vertex and fragment shaders; however, that only implies a need for interface matching, rather hard-wiring. Defining an inter_shader_interface type, and a shader_pair class that can only be formed out of vertex and fragment shaders whose interfaces match. Something like that.

Well... after working a bit with shaders (remember I had no experience earlier), putting shaders with materials is the only choice.
Not only interface matching is the problem... sometimes, you just can't separate the concepts.
For instance, if you're using no special vertex processing in an ambient pass, but need a vertex shader for the diffuse/specular part because you're doing per-pixel lighting (I went there already... I'm telling my experience), then you'll find out you need a vertex shader for the ambient pass.
This is because the fixed-function pipeline doesn't agree with the shader in the second pass when it comes to z-buffer sampling, and the result is ugly z-fighting. You could apply an offset, but that's uglier (eats up z-buffer precision).
So... in fact... the material has to dictate: I need a vertex shader here and there.

However... I've managed something similar to what you described with material templates... that is, you have some parameters unspecified in them (ie - shader variants), so you can control from the outside a few details about the material, like "replace this shader by the blabla animation shader". You only have to match the output of the animated vertex shader to the expected output, and everything will work fine.

Of course, my templates don't have that kind of parameterization... I hadn't thought of that. But, it's an easy hack - although will make templates unreadable.

Oh... and you can add vertex colors (both diffuse and specular) and any number of texture coordinate sets. That's, for instance, how tangent vectors are placed in meshes (that's a mess... you have to know the texture coordinate index of the tangent set).

So, in fact, materials are (at least in Ogre, pre-template) per-submesh. Not even per-mesh. Templates, however, allow you to write a generic material and instance it with specific parameters for each submesh, which is really a nice tool for artists. I'm working on a template instancing script right now, and when I have that ready, I'll commit a branch to CVS so you people can try it out (it's not on the VS engine, but a test app that spawns a system and lets you "fly" in it).

Given the amount of RL work turning up, that'll take a while - a week or two. I'll make a backup though - don't panic.

[chuck_starchaser]

Of course, my templates don't have that kind of parameterization... I hadn't thought of that. But, it's an easy hack - although will make templates unreadable.

Best way to parameterize a template is by a single type. Declaring all the data in a nicely named struct, then parameterizing by the struct, and only using a pointer to the struct within the template, so it doesn't depend on the struct's size, so the code for all the templates is the same, they only differ in type for compile time type checking purposes. Anyways, I didn't understand a word of your first paragraph, but somehow you convinced me...

[rewpparo]

About vertex shaders in material, even without the coding issues, I believe it makes total sense. indeed an hydraulic cylinder is an hydrolic cylinder, regardless of his texture. But even before that, it is a cylinder. You may want to use the mesh data for something else. it is then a lot more efficient to define a new material script, than to store two versions of your mesh, one with the shader and one without. So I like this organisation.

[chuck_starchaser]

I think I'm getting the jest of what you guys are talking about. Basically, you see the vertex shader as front end to the fragment shader. In a way it is. A lot of fragment operations can be offloaded to the vertex shader, assuming interpolation of the per vertex results is roughly equivalent to computing the function from interpolated vertex data. And probably this is a more common use of vertex shaders than actually manipulating vertex positions and stuff.
Makes sense now.

[Lowkey]

What about distributed computing?

http://distrit.sourceforge.net/

It could be done like this...

When a clan gets to 50+ members it can settle a colony. The members of the colony could run a screen saver when they are not in the game to keep colony´s ¨gate¨ open. When the colony gets to 100+ it could research new things to build. By that time the devs would know how big the next step would need to be to keep items created persistent. The colony could be used as a spawn point if you belong to a colony. It would also encourage people who wouldn't want go in to deep space but would like to roleplay increasing the computing power and a depth of play no npc could come close to.

If it wasn't done that way it probably could be used for scale.

[Calvin]

sorry for digging out an such old thread, but i wanted to know if there will be someday a ogre3d port or if you stick now with your engine?

if you switch someday to Ogre3D will you use the PhysX Accelerators(either way, as now the cards or dunno whats Nvidia doing with it, maybe add it to the gpu or put a second chip on the card) as Ogre is PhysX compatible. would be nice to have a physical realistic depris system for the ships. would be nice to have it even when no ogre port is made

Hope you guys havn't given up with seamless planetary flight and walkable ships and bases.(and a shiptakeover for the FPS fans^^) like this games 1 , 2 , 3

Like docking with a pirate vessel on a big disabled capital ship and trying to commandeer it.

Hopefully someday i see a great damage model, where you can should a ship into small pieces and you can see as you break the hull that air is venting and people

in the end vegastrike will have all great thinks from all genres and you only need to play one game and as it is open source it will get every day better

yeah, i know most of it would need a supercomputer, but it would be nice to see as much as it is possible

[bgaskey]

The OGRE port is still on tap, but probably won't get any more work done on it for at least a year or so. (see development plans here: http://vegastrike.sourceforge.net/forum ... 36&start=0)
OGRE would allow some cool stuff, but I don't think its a real necessity, this is really a space sim after all, and I don't really want walkable bases or planetary flight, although if they were added I guess it wouldn't hurt.

[klauss]

Ya, Ogre is kind of low priority, however it is there on the roadmap - the "rewrite" or "refactoring" of graphics is that, I believe.

However, I wouldn't be very confident about that PhysX thing... I don't think Ogre helps much in that department - though I could be wrong. PhysX is for physics only, I doubt Ogre will have any kind of support for that. And the poor thing seems ill-fated already, with GPU manufacturers pushing more and more on GPGPU.

[Calvin]

@bgaskey: As i mostly play RPGs i don't need much grafik, i would be fine when it has a grid so you see where it is and how big, no textures needed. But from a spacesim i like most realistic physics. 100% realistic solar systems and body movements would be greate. and as i wanna experience it not only in a spaceship, but would like to see the sun go down behind a planet on a spacestation too. As in every genre there are some features, bot none has all in it. when i could effort 9x-Plane (Pictures) i would play it

@Klauss: As i found this site and i'm thinking as my GPU is somewhat working hard(EVGA Geforce 8800 Ultra Superclocked) on the highes resolution and full detail and most games i play in LANs support PhysX i'm playing with the though to get a cheap card. ok, the new Coba(?) code from Nvidias PhysX should work on mine too, but i hope it will stay compatible to the PPU cards, to get some load from the grafic-card to another device.and if they hopefully get a news out if they will break compatibillity or not to the PPU cards or keep selling those for the lower grafic-chips so that you don't have to update the card for the physics and for the shaders in the next few years.

[klauss]

That NxOgre is a different package, its only link to Ogre is that it's designed to interphase with Ogre. Which... granted... would make the switch to Ogre turn support for PhysX on VS a little bit easier.

Still, PhysX is designed with cloth simulation and particle physics in mind - perhaps, though I'm not entirely sure (and I'm leaning to the negative), rigid body systems too. But a full dynamics engine is far more than that, and VS right now has little use for PhysX acceleration. (most of the difficult stuff is stuff where PhysX won't help).

I might be wrong though.

[bgaskey]

As i mostly play RPGs i don't need much grafik, i would be fine when it has a grid so you see where it is and how big, no textures needed. But from a spacesim i like most realistic physics.

I was just saying that those two features are the most common reasons people want an OGRE port, and I don't think they're valid for this game.

EVGA Geforce 8800 Ultra Superclocked

Wow I'm jealous. I need some of that

As Klauss said, I think the speed increase from adding PhysX would be minimal and that developer time would be better spent elsewhere, but it is always a possibility that it could happen