Graphic engine and graphic technologies

[CubOfJudahsLion]

I find myself asking the same question I saw in the first page: VS's already got an engine that supports the OpenSource cause as an integral part of a OO project, handles the particular requirements of the game and it's getting a shader upgrade that's likely to be a lot less work than porting to another rendering engine, which wouldn't provide any code solutions for implementing other flight scenarios or improve the existing one in any way. Sure, ragdoll/softbody dynamics are nice, but ships are not made of cloth.

"Why all the fuss", indeed?

[charlieg]

I've been looking a little bit at VS's source code... [Ogre3D] has a structure that is very similar to the one used in vega strike (if you want to look at the doxygen doc, universe = scenemanager, unit = entity, etc...) so I believe a port is just a matter of binding existing functions to ogre instead of VS's current graphical engine.

Just because you are getting a bit of friction here, don't let that discourage you. If it did turn out to be relatively simple [as simple as switching from one 3d engine to another can be] and there was a prototype, I'm sure the idea woudl gain momentum and developer favour. I bet HellcatV and the other devs would rather spend a little while adapting the VS model format and/or it's various tools than implementing all the various 3d features that Ogre supports and no doubt implements better than VS could hope to do.

The problem is that Hellcat & Co are stretched as it is. They won't really have the time nor desire to start a port from one engine to another based on a whim. What I'm saying is, if you think it's that simple, start having a go. The worst that could happen is you'll improve as a programmer, the best that your concept works well and VS integrates your changes and Ogre3D. Or something inbetween [you'll spot ways to improve things or fix bugs].

Go for it, I say. There's no reason not to. Don't let a few "if it ain't broke don't fix it" people put you off. [Heh, they probably have an all-black wardrobe, since black is safe.] If HellcatV didn't want people like you to experiment with the code he'd never have released it as GPL.

This could yet be a brilliant idea.

[chuck_starchaser]

World coordinates of objects are kept in doubles, so one has centimeter accuracy on the origins for each local coordinate system up to ~ 70 billion kilometers (~2.7 Light-days) from the origin of the star system. We've been considering precision issues surrounding star system scales for at least the last couple of years (exact timeframes escape my memory), and believe the fundamental support mechanisms for such to have been addressed quite some time ago.

Let's see, 1 AU = 149 598 000 000 m
149 598 000 000/2^64=0.000000008m = 0.000008 mm = 0.008 um = 8 nm
This is GOOD!

However, once we're on the ground, we'd probably want to make our world coordinate be that of the base or city we're in, rather than keep referring ourselves to the center of the star system; but I guess one could make a switch then. Doesn't have to cause even as much as a blink. Should work...

Sure, ragdoll/softbody dynamics are nice, but ships are not made of cloth.

On the ground everybody's gonna want ragdolls and softbodies, though.

[CubOfJudahsLion]

On the ground everybody's gonna want ragdolls and softbodies, though.

*beep* parser error 101: if statement required before line.

[chuck_starchaser]

After a whole night fighting in space, wouldn't you like to sit at a place like this? (In 3D, of course..)

[Halleck]

The only reason to implement another engine would be to handle that planetside stuff that was being discuseed.

As for the space engine: changing it would be ridiculous. Why would hellcatv work for years on a custom engine that suits our needs, and then just randomly decide to dedicate a huge amount of effort to switching to another engine that suits our needs less? It makes no sense whatsoever, and would be utterly pointless.

[chuck_starchaser]

Agreed. My biggest worry was precision and it has been dispelled. In fact, the precision using doubles for the star system actually beats the precision of local coordinate systems on the ground. 8 nanometers is superb. So the engine as is could handle atmospheric flight all the way to landing. Just a matter of implementing planets with sub-object (terrain patch) LOD-ing. Once on the ground, though, we should consider Ogre, I think.

[Halleck]

Yes, first-person planetside/base mode is another matter entirely.

[rewpparo]

actually everything people said here comes down to : can we do it ? Well, we won't know until we try. So like charlieg said, let's do it. However, I'm not a very experienced programmer, is there an IRC chan where people hang out that could give me pointers on how things are done in VS, in case I need it ?
Main concerns seem to be about hudge distances in space (Z buffers and coordinates), and the fact that ogre maybe isn't expandable to an all purpose engine. I believe Ogre has enough flexibility to do that, and if it doesn't, sinbad (ogre's lead programer) will take our remarks seriously and work on it on his end. After all his goal is to make the ulimate graphics rendering engine.

[chuck_starchaser]

Sorry, made a mistake, the "long double" has 64-bit mantissa. The IEEE double has 53 bits of mantissa, so,
1 AU = 149 598 000 000 m
149 598 000 000 / 2^53 = 0.000016609 m = 0.016609 mm = 17 microns.
Still superb.

@newpparo: Give us a breakdown of what Ogre can do on ground. Like type of shadows, collision, physics (gravity, inertia, elasticity, water waves, liquid physics, fire, smoke, skels, muscles, clothes, hair, faces, expressions, pony-tails?), does it have rendering to multiple surfaces? One very important thing: Being able to render to off-screen contexts in batch mode, such as to have gradually updating, dynamic cube-maps (dozens of them). And continuity: Has anybody demonstrated a level-less, continuous world implemented in Ogre? And of course, what kind of performance to expect.

[rewpparo]

Well first ogre is a GRAPHIC rendering engine. it has no physics, networking, or whatever. it specialises in graphics, and does it well. However it has been used sucessfully with many physics libs, like tokamak and ODE, with great results, like ragdolls physics. It does have some physics features out of the box, like BSP colision and water effects, but those serve mainly as an example.

as for features, have a look there
http://www.ogre3d.org/index.php?option= ... &Itemid=62
Supported shadow techniques aren't listed, they include stencil, texture based shadows, modulative shadows, and additive light masking.

To my knowledge, no one has tried to make a complete seamless world in ogre. Most applications developped with ogre are quite specific like car races. However, Ogre is a on demand engine. basic implementation has little to no features/optimisation. It's just a high level API for openGL and direct X. You can then activate any kind of optimisation depending on your needs, or develop new types of objects with the optimisations you wish.
What I mean is that if openGL can do it, ogre can do it. it doesn't limit you to anything, offers optimisations if you wish them, and leave you freedom to implement your own optimisations, that would benefit behind the scene of any special effect you wish to give it (bump mapping, shaders..)

Just as an example, I'll talk a bit about my planet plugin. I wanted a planet that could add detail when you came close by. I made a new object that looks like a cube in its early stages, that divided up as you came closer, and maches more and more the shape of the sphere. I made a new object, going from a high level "planet" class down to vertex buffers in the GPU. yet I could still benefit from all materiial features of ogre, and I am still able to use any other objects types, like billboards and particule engines, around my planet. That's for the flexibility of ogre, and I believe that is its main strenth. Doesn't corner you to do anything you don't like.
However, this engine only has a couple of years, and came to a level where it can actually be used for production about a year ago. Many plugins have and will develop, allowing you to do anything you want.

[chuck_starchaser]

Allright, so Ogre is more of a rendering back-end. We could keep 90% of the VS engine as is and substitute Ogre for the current back-end. That's very sweet because the back-end in VS was slated for a major overhaul anyhow. Not just adding shaders, but primarily dealing with materials management in more sensible ways (right now for instance if two ships using the same mesh call for different textures, the mesh has to be instantiated twice). So, I defer back to Klauss' concern about z-buffer issues. I think what we would need from Ogre is the freedom to tweak z-buffer possibly in the vertex shader. What I was just thinking, as a first approximation, is: For each objects in the scene, in the CPU side, and using double precision, we'd compute real distance from the camera to the center of the object, and to the nearest and furthest points, compute the log of these quantities, scale them as necessary, reduce their precision to match z-buffer range, and pass them to the vertex shader; which in turn would extrapolate the incoming vertexes for that object to fit the desired range. As a second order optimization, for, say, 16-bit z-buffers, we could detect and remove unused z-buffer ranges, so as to optimize the utilization of the available precision.

I find this awsome, BTW..



I've read through your features link, and what I'm still in the dark about is whether I can have multiple rendering contexts, and whether there are limitations as to their number and so on. Let me explain to you what I'm after in more detail: I'd like to implement dynamic sky-boxes (cube maps) and bill-boards, that are updated slowly, but displayed in real time. So, for instance, a planet doesn't change much within itself from frame to frame, so I could have a multi-pass rendering pipeline to an off-screen double-buffered context, which pipeline completes the rendering in, say, 8 frames' time, then swaps. This off-screen surface is projected onto a flat billboard substituting for the planet, in real time. So if I accelerate towards the planet, and the planet grows in size by 1% or 2% within 8-frames, I can see that continuous change (billboard getting bigger) in real time.
Or, say I'm in a city like LA, surrounded by mountains or hills. If I were driving through LA, my perspective of the hills in the distance would change gradually, so they couldn't be put on a fixed "skybox", but a dynamic skybox would work: I'd only have to update it once every 256 frames, say. But I'd have many other, smaller skyboxes that would need to be updated a bit more often, such as one onto which I render city blocks that are 5 blocks away. For this I'd need, say, 4 cube maps, at 6 surfaces each, that's 24 surfaces, say 32 for some extra dynamic billboards. So 32 off-screen rendering contexts, all double-buffered.

[rewpparo]

Well all this goes beyond my knowledge. i never went that far in the use of ogre, but I'm eager to try it out.
i suggest you go to the ogre forum and ask your question there, you'll get a very fast and acurate aswer, better than I could provide even if I spend the whole week end in my ogre docs.
you also have IRC, #ogre3D@irc.freenode.net. lots of nice people hanging around, and some could aswer that kind of question.

[chuck_starchaser]

Thank you, I've registered at the Ogre forum and put my questions under the General Discussion sub-forum.
http://www.ogre3d.org/phpBB2/viewtopic. ... 0616#80616

[hurleybird]

Does ogre support, or plan to support HDR?

[Halleck]

Hehe. Always after that HDR, huh?

[chuck_starchaser]

So, I wasn't the only one losing sleep over low RGB numbers and what to do with the high end, eh? This ought to be put in!

I did something like it with my Earth's atmo: I had a color /= sqrt(1.0+color^2) so that it would saturate gradually towards the horizon. But dynamically adjusting dynamic range for the whole scene is definitely the way to go.

http://www.gamedev.net/reference/articl ... le2208.asp

I'm thinking of an "RGBX" format: 8bits each RGB, then 2 bits (lsb) for exponent and 6-bits (msb) for alpha channel, since 4 doublings of dynamic range ought to be enough; --after all, video DAC's are 10-bits at best--, and having alpha is useful.

EDIT: Come to think of it, I think this RGBE idea is not that good. Dynamic range between pixels in a texture wouldn't make much of a difference; what's needed is a single floating point RGB vector multiplier for the whole image, so that however dark a texture should be, relative to some average material texture, it can still use the full RGB dynamic range. I wonder if most image formats reserve some free space where one could stick these 3 floats...

[hurleybird]

Hehe. Always after that HDR, huh?

HDR is still, IMO, more suited towards a space sim enviroment than anything else.

[klauss]

HDR is still, IMO, more suited towards a space sim enviroment than anything else.

Amen.
HDR alone would push VS visuals rocket high.
HDR+shaders (bump and stuff) would be a dream.
HDR+shaders+global lighting... a heart attack.

Just imagine the dynamic range that can be found within space-like lighting:

* Looking at the sun directly.
* A planet lit by the sun on one side, and the darkside of the planet.
* A station on the planet's darkside, with the moon behind, casting radiosity lighting.

Wow... (drools)

[pifactorial]

BTW, looking at the webpage, Ogre does support HDR (new feature).

[chuck_starchaser]

Allright, team-mates, let's do it; let's conquer HDR; I can take care of the light math and shader side. We need a comprehensive approach to materials. We were saying that vertex shaders belong in the meshes and fragment shaders in the materials?
I think we need a class txtr_diffuse, a class txtr_specular, a class txtr_radiosity, a class txtr_translucence or whatever, all of which inherit from a class texture. But class txtr_diffuse includes a vector of 3 floats that multiply the texel data from the image file on load. Each of these texture sub-classes must be savable to a file that is a proxy to the actual image file; or else textures could be saved as records in a database table that references the images.

(Note: I won't post anymore today; I keep getting PhpBB Critical Error 9 times out of 10, and I'm too busy with work anyways.)

[rewpparo]

Well I don't really know whether or not i've convinced people to use ogre, however that will be your decision as I can't work on the port right now. I's a busy time for my work (which btw has nothing to do with programing), and i'll soon be off for training without a computer for a couple of month, So i don't think I'll be able to start working on any project before october. And I still need to find out how to setup kdevelop under my gentoo ^^

Anyways, This topic at least made some ideas pop out ^^

[klauss]

FYI, I kind of like the idea of using Ogre for the planetside/base interface, if VS's own engine falls short of meeting optimization requirements (after the port to GLSL, which will be quite an overhaul).

And about HDR: Let me say that I've never liked the final post-processing most HDR titles perform, too low quality. With as few as 3 to 4 downsampling/filtering passes, a high quality effect is easily achieved. When we get to it, I'll clarify.

[hurleybird]

And about HDR: Let me say that I've never liked the final post-processing most HDR titles perform, too low quality. With as few as 3 to 4 downsampling/filtering passes, a high quality effect is easily achieved. When we get to it, I'll clarify.

I think I know what your talking about. Source engine HDR looks like ass. Crytech's on the other hand, is quite good, but not perfect.

[charlieg]

There are many positives to porting VS to use OGRE for everything rendering.

1. OGRE is very actively maintained / developed - 1 less thing for the VS devs to worry about
2. Commited to API stability too, so future updates should not impede VS
3. Support a large number of features VS does not yet have, saving on development time, effort, and expertise
4. The extra features mean that any future base / planet work would have a lower development barrier
5. OGRE is optimized well - wide ranging video card support and fast rendering
6. There is some great GUI options with OGRE

And I'm sure there's more benefits to using it.

There is but one downside to using OGRE. It needs prototyping, somebody needs to have a go. Really, why shove all this effort into bump mapping, HDR, and shader support [to name but a few] when it's available in something like OGRE. It's almost non-sensical to do it manually. OGRE is not suffering from the same development issues that affected CS to the point that VS had to totally split it's engine.

Just think of all the time that could be saved from using OGRE. Even better, think of what could be done with all that saved time...