FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Starting
Goto page 1, 2  Next
 
Post new topic   Reply to topic     Forum Index -> Sinbad
View previous topic :: View next topic  
Author Message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Thu Apr 22, 2004 11:08 pm    Post subject: Starting Reply with quote

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
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Apr 24, 2004 2:37 am    Post subject: Re: Starting Reply with quote

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


For goals: I would like Sinbad to become a professional quality toolkit.
Styleguides: Do you mean codeformatting? In that case I'm most happy with the one used by www.coin3d.org (at the bottom). It's C/C++ centric but it's easy to convert it to D. It's simple, not destroyed by tabs and makes it possible to nest deeply without wrapping.
Todo list: To be able to test anything ASAP, a gui binding is needed. I'm looking at DUI at the moment, so maybe I could try to port OGRE's gtk-stuff to DUI?


From Coin's HACKING:

Code:


7) Code formatting rules. The default is to use Kernighan and Ritchie style.

   a) Braces: keep opening braces on the end of the line, and closing
      braces at the start. Like this:

      if (...) {
        ...
      }

      And not like this:

      if (...)
      {
        ...
      }

      The exception from this rule is functions, which should have the
      opening brace on the next line.

   b) Indentation: use 2 spaces extra for each level of nesting.

      *Never* use tabulator characters (ie ASCII code 0x09), as
      editors expands them differently. The code indentation will
      therefore more often than not look like crap with the default
      settings of any other editor than the one you happen to be using
      yourself.

   c) Spacing: use 1 space after commas and around operators (like +,
      -, *, /, ==, &&, etc), but not after or before parentheses.

      Like this:

      if (val) { i = sqrt(a) * func(b, c); }

      Not like this:

      if ( val ) { i=sqrt(a)*func(b,c); }

   d) Naming: class names should be uppercased for each word, function
      names for each word except the first one, variable names should
      be all lowercase, and defines, enums and constants should be all
      uppercase. Example:

      float
      MathClass::calculateValue(float in)
      {
        const float FACTOR = 2.78;
        ...
        ...
      }

      For C functions and C++ functions that doesn't belong to any
      particular class, name them with underscores between words, in
      all lowercase.

      NOTE: do *not* use Hungarian-style naming, ie prefixing names
      with indicators about type. So don't for instance name classes
      with a leading "c", or member variables with an "m", or integers
      with an "i" and so on and so on. You're better off in the
      readability-department by using the "this" prefix, as explained
      above, and then the Hungarian naming style just obfuscates the
      code.

   e) Pointer types and references: use a space on each side of the
      '*' and '&' operators, like this

        SoNode * mynode = NULL;

      not like this

        SoNode *mynode = NULL;

      because it makes it look like the '*' "belongs" to the variable
      name (which of course is wrong -- it's part of the type), and
      not like this either

        SoNode* mynode = NULL;

      because it's ugly and unusual. So for consistency, _please_
      stick with the space-on-both-sides convention in Coin code.

   f) Use
                   return x;
      and not
                   return (x);

      (Since "return" is not a function with arguments, the latter
      just looks plain wrong.)
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Sat Apr 24, 2004 9:44 am    Post subject: Re: Starting Reply with quote

larsivi wrote:

For goals: I would like Sinbad to become a professional quality toolkit.

I'm hoping it will!

larsivi wrote:

Styleguides: Do you mean codeformatting?

Yes that's what I meant... and I do like the one you've pointed out. I'll write up a suggestion based on that in a bit... Would also like to start a list of conventions to be used... aka, do we rely on D-style properties or do we use get/set methods, for instance. And should we I-prefix interfaces (even though Hungarian is evil) so they stand out. I'd also like to make thorough use of DbC where possible. And it'd also be nice to pick a commenting style that suits most people. Not neccesarily the play-by-play comments, but for the "header" comments (ie, those coming just before function or class definitions, the module-top comment, etc). And do we want to use any third-party documentor, like doxygen.

larsivi wrote:

I'm looking at DUI at the moment, so maybe I could try to port OGRE's gtk-stuff to DUI?

Would likely be handy for early testing.. if you're feeling torturous, have at it. Smile
_________________
Chris Nicholson-Sauls
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Apr 24, 2004 10:01 am    Post subject: Re: Starting Reply with quote

csauls wrote:
Would also like to start a list of conventions to be used... aka, do we rely on D-style properties or do we use get/set methods


I like using D-style properties, but then you need some sort of prefixing of the private variables (p_ for example). I find that a rather small evil, though.

csauls wrote:
And should we I-prefix interfaces (even though Hungarian is evil) so they stand out.


I prefer i-prefix before I-prefix, but will there be much use of interfaces?
Another thing, due to the D module stuff, the capital letters in the directories probably should be small in Sinbad's hierarchy. Also, the dir's named src should be removed, othervise we would get sinbad.src.foo; type module names.

csauls wrote:
And it'd also be nice to pick a commenting style that suits most people. Not neccesarily the play-by-play comments, but for the "header" comments (ie, those coming just before function or class definitions, the module-top comment, etc). And do we want to use any third-party documentor, like doxygen.


I like doxygen. I think we should try it (It's what's OGRE is using also). I guess we don't have to rewrite all the documentation, that's a good thing.

csauls wrote:
larsivi wrote:

I'm looking at DUI at the moment, so maybe I could try to port OGRE's gtk-stuff to DUI?

Would likely be handy for early testing.. if you're feeling torturous, have at it. Smile


I've already started, but I'm having some trouble with DUI itself and more. It'll probably take awhile.
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Sat Apr 24, 2004 10:51 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sat Apr 24, 2004 1:13 pm    Post subject: Reply with quote

csauls wrote:
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


Close enough! Smile Great writeup.
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Sat Apr 24, 2004 2:55 pm    Post subject: Reply with quote

Thanks. Smile

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
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Sun Apr 25, 2004 2:39 am    Post subject: Reply with quote

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

csauls wrote:


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


Well, I'm not sure we can capture much more before we have anything to show. It would have been nice though.

As to the OGRE objects, it seems like much of it is inspired by the Open Inventor API (altough OI use quite another methodology for it's execution). This I find good, as I've worked quite much with Coin (which is an implementation of the OI API). I've actually wanted to make OGRE in D, just didn't know about OGRE Smile
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Sun Apr 25, 2004 7:53 am    Post subject: Reply with quote

larsivi wrote:
I've actually wanted to make OGRE in D, just didn't know about OGRE Smile

Same here... went looking for different engines to get ideas from, and stumbled across it. Toyed with it a little and thought it might be an ideal candidate.

A possible use for interfaces that I've seen, is for plugins. One could, for instance, change how the environment behaves be creating your own iSceneNode implementation (or maybe subclass of AbstractSceneNode?) and store an instance of it in some static variable representing a SceneNode factory, or the like. Just ideas I'm looking at.
_________________
Chris Nicholson-Sauls
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Tue Apr 27, 2004 4:28 am    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
eye



Joined: 03 Jun 2004
Posts: 5

PostPosted: Wed Jun 16, 2004 5:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Wed Jun 16, 2004 12:25 pm    Post subject: Reply with quote

eye wrote:
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.


I don't think csauls evaluated all the engines out there to find which one to convert, although I think he made a good choice. Nebula I know little of, but a quick look make me think it's quite similar to OGRE in it's philosophy. I HAVE looked at OpenSceneGraph with the same thought that csauls had about OGRE, but the documentation sucks. As for how it works, they say they are inspired by SGI's Performer (which isn't necessarily good for non-highend-graphicsprocessing machines (at least I heard that somewhere)). I think scene graphs are a GOOD thing (and OGRE use them in it's own peculiar way), but OpenSceneGraph do it in a way that really alienate me, probably because I learned about scenegraphs through Open Inventor (Coin).
Back to top
View user's profile Send private message
eye



Joined: 03 Jun 2004
Posts: 5

PostPosted: Wed Jun 16, 2004 3:18 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Thu Jun 17, 2004 3:21 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
eye



Joined: 03 Jun 2004
Posts: 5

PostPosted: Thu Jun 17, 2004 6:39 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Sinbad All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group