Starting

csauls · Joined: 27 Mar 2004 Posts: 278

First and foremost, we should all get ahold of a copy of OGRE for C++, and its documentation, via:
http://www.ogre3d.org/

Its an unusual design for a 3D engine, using objects to represent not only utilities and the like, but also the virtual world itself and all it contains. Light sources are objects, as are terrains, the camera, and everything else involved. There are material objects, overlay objects, particle system objects. Thus one of my ideas: D's lighter objects should be a blessing to this design.

This should open the door for game (and other 3D interested) developers looking for a relatively simple platform, and provide D with a nice proving ground.

Once we've managed (eventually) to come up-to-date with OGRE, I'd like to work on some revolutionary plugins as well... but all that's to come much later. The only one of particular mention is the as-yet-unnamed 3D sound plugin. I mention it only because I'd like to see Sinbad designed somewhat aware of it, perhaps turning on direct support via D's versioning system.

But aside from all that: I'd like to hear everyone's suggestions for goals, project-wide style guides, todo list, etc.
_________________
Chris Nicholson-Sauls

larsivi · Posted: Sat Apr 24, 2004 2:37 am Post subject: Re: Starting

csauls · Joined: 27 Mar 2004 Posts: 278

larsivi · Posted: Sat Apr 24, 2004 10:01 am Post subject: Re: Starting

csauls · Joined: 27 Mar 2004 Posts: 278

I can't swear on how much use interfaces will get, but I'd like to be ready for them. I like the D-style props as well, so that may be the way to go. I've got the beginnings of a styleguide written. View it at:

http://www.kydance.net/~invironz/proj.php?sect=sinbad&sub=styleguide
_________________
Chris Nicholson-Sauls

larsivi · Posted: Sat Apr 24, 2004 1:13 pm Post subject:

csauls · Joined: 27 Mar 2004 Posts: 278

Thanks.

I'm about to start looking at how the OGRE objects relate (lineage, etc) and how it might translate to D... will start a new thread for it once it gets somewhere...

Speaking of which... we need to try to get a couple more people in on this. I doubt the two of us (whom I know are both busy with other things too) could get much done too quickly... not that there's any rush. Wink

_________________
Chris Nicholson-Sauls

larsivi · Posted: Sun Apr 25, 2004 2:39 am Post subject:

On more thing before we get a repository. We should make good and informative change log entries when committing changes.

csauls · Joined: 27 Mar 2004 Posts: 278

larsivi · Posted: Tue Apr 27, 2004 4:28 am Post subject:

Just found out that OGRE is not really much like Open Inventor. This means that I have to think differently about things. More to learn...

eye · Joined: 03 Jun 2004 Posts: 5

Have OpenSceneGraph and Nebula1 been evaluated as well? I believe Nebula1 (zlib-like license) has a few interesting ideas, especially how scripting and serialization is done. And it seems to have some mighty performance tuning, like avoiding state changes, and "memory management" to have as many objects as possible in as few as possible buffer objects.

OpenSceneGraph is interesting with its support for occlusion culling.

larsivi · Posted: Wed Jun 16, 2004 12:25 pm Post subject:

eye · Joined: 03 Jun 2004 Posts: 5

I also looked at DevLib and G3D, and there seems to be a common situation: as the number of objects grows, even with moderate vertex count the performance fades away. Even if the objects are untextured, use up very little fillrate, and are declared static. With a couple of hundred objects, it only seems to do like 4 Mio vertices per second, while my hardware should be capable of 17 Mio. With one static object, at the contrary, one easily comes quite close to that this capability limit. That makes me think that it is a great pity that performance gets wasted somewhere.

Reading vertexbuffers.txt (and nmeshnodes.txt) from Nebula documentation package, makes me think they might have tackled the problem successfully, although i didn't have a chance to make sure myself.

One major difference of Nebula to other open-source systems is that it's not an open-source effort itself, but rather a source release of a performance-critical core of a commercial game Project Nomads, which is said to have reached gold sales status here in Germany. I haven't checked it out though.

larsivi · Posted: Thu Jun 17, 2004 3:21 am Post subject:

The capabilities of your card is of course purely theoretical. Vertex buffers is a new way to send vertices to the card and is unlikely to be supported efficiently on older cards. As to why the libs you mention isn't able to utilize the cards capabilities fully, many factors come into play. How the engine organizes the data is the most important. Engines usually help with occlusion culling so that the card only handles stuff that is really visible. Also, the CPU is often the bottleneck in the system, meaning that if it has to do work on the geometry, it's seldom able to process as many vertices as the GPU. Organizing objects smartly is often very important when doing performance tuning.

eye · Joined: 03 Jun 2004 Posts: 5

The capability is not purely theoretical, it is quite well reached by the landscape demo from DevLib, which uses one huge static VBO. Even despite of multiple overdraw, full screen rendering. My card is the lowest performance of the curently produced cards, GeForce FX-5200.

And while VBOs simply don't work on older hardware, or don't make much sense, there simply are fall-back paths to utilise more standard means. Processing geometry on CPU is the silliest thing to do nowadays, where almost all cards in use have hardware T&L, and most even vertex shaders. Only hierarchies have to be processed on the host. Even basic T&L hardware supports 2-matrix skinning. So CPU is really, really not a bottleneck. The GFX cards get faster at a much higher rate than CPUs, and even now are multiple times as fast at vertex processing.

G3D and DevLib don't have any occlusion culling. And i have yet to find a generic occlusion culling scheme. OSG seems to use shadowvolume based occlusion culling, of which i'm afraid it may tend to be slow, so unless one knows exactly what to do better not use it. I also found that this sort of occlusion culling can be accelerated in hardware by doing a rectangle occlusion test (GL_ARB_occlusion_query). Another interesting scheme is using sort-of raycasting in octree domain, as Cube and Sauerbraten do it. The one most interesting for closed static environments is portal tracking. All but octrees requiere manual selection, such as selection of very few strong occluders for shadowvolume occlusion, or specification of portals. I've seen systems to generate portals automatically, and i must say i was not very amazed.

Looking at dPVS, a commercial occlusion culling system, it seems extremely complex and combines all of the above techniques. It has been built as a result of graduation work of one finnish student, which i'm going to look at.

All this is a decision of selecting a target. I'd say it's sane to make a system which would be able to take most out of the current cards, which will mean that it's not too old when it gets ready. If we just target a low performance system, we're left far behind.

BTW, i had a look at Project Nomads. Its geometric complexity is very high but not overwhelming. The game is almost completely fillrate-limited, due to a good LOD system on the one hand, and a lot of atmospherics on the other hand: realistic clouds, best looking trees i've ever seen, and they're not scarse at them.