Ok I am well into designing a hybrid 3d engine based on a combination of portals and dx meshes.
The way it works is to assume that we have a 3d world built from "sectormeshes" in which I am encoding the "portal surfaces" by using a custom Material to identify them within the mesh. Each sector of the world is thus kept as a separate X-file, with the Level File being a list of which sector meshes to load, a linked list describing the portal links between them, and for each sector, a further list of regular objects (also xfiles) to be loaded, and their initial rotations/scaling factors relative to the sector they appear in. I have recently been getting some flak about not using BSP to encode the individual sectors instead of keeping them as intact DX meshes. I have been planning to implement all of this under Retained Mode and that is just one reason why I haven't used BSP so far.
I am looking for feedback and input.
What would YOU like to see in a 3d engine?

Posted on 2002-05-25 10:38:16 by Homer
I guess the mere mention of ASM sends them packing in hoardes.
Depressing response to this thread considering the topic.
Nevertheless, I shall continue to design and code this monster, and I am writing a tutorial as I go.
In fact, some sketches and notes are available if you look for my link on the links page at Sally's Site (look for Evil Homer's AI Engine, the first page has a link to the Game Engine near the top)

Have a nice day.
Posted on 2002-05-31 10:57:02 by Homer
I'd like to see a games engine using NURBS instead of polygons. :grin:
Posted on 2002-05-31 12:47:24 by bitRAKE
No, sorry. Too expensive in terms of cpu time.
Not possible until curves are better supported in hardware,
or cpu clocks are a lot faster.

I'm concentrating on making more of what IS possible under software, which is more flexible control through hierarchical structures of the hardware-acceleratable primitives encoded within them.
Posted on 2002-06-01 04:56:58 by Homer
Will there be any collision detection involve?

If so building a BSP for each sector (if there are complex enough that is), could pay up in the long run.

That is unless you want modifiable geometry. (like when a misile hits a wall and you can see the hole on it afterwar). In that case you could use a mini octree for the rooms(or another structure).

Level of detail could be a good feature for static meshes in the room. (that way a user with better hardware could have better detail). If there are no outside levels, this could be done one time at the beginning of the program, you could use an algorithm aproach or build each level of detail and then load the correct one.

Realtime shadows (if running on hardware aceleration) have become sort of standard this days, but that will depend on the level of realism the art of a level have.

Maybe NURBS could not be done realtime, just maybe, but you could always precalculate the polygons to send to the card based on user settings.

Also, try to make the engine as modular an scalable as possible. (But please, dont try to get so OOP to make the engine slow.). One feature you sould look for is hardware accelerated pixel and vertex shaders. But its implementation should be completely optional (unless you are writing for XBox, in that case they should be in).
Posted on 2002-06-01 09:35:06 by dxantos
There will most definitely be collision-detection involved.
Most impostant will be detecting collision with Portal Surfaces, because that means something is leaving this sector (and going through the portal).
As for BSP, the whole point of portaling is that we have reduced the World Surface polygon count down to a mere handful of surfaces (excluding instanced objects,characters and particles).
Collision-detection against World Surfaces is now very cheap, in fact, it's cheaper than if we had to walk a BSP tree !!
Anyway, if people insist on using the Portal feature incorrectly, ie, not assigning enough portal surfaces causing large polygon counts in sectors, then I can always add BSP later on.
For now, the whole concept of this is to avoid walking down the same paths as those who went before us.
I wish to encourage those with a coding background who would like to get into gamecoding by writing a similar document to Chris Hobbs' Tetris example, but for 3d, and for dx8.
Posted on 2002-06-01 11:05:54 by Homer
I have tough of writing an article for using Win32 assembly with OpenGL. But I really don't know if people would be interested since there is already much C/C++ information on the subject.

Also dont know if the article should be very basic (Nehe style tutorial), or more advanced (NVIDIA style ones).

I have one question for the engine, I had a similar idea of using materials for identifiying portals, but got the problem that placing the portals required too much dicipline on part on the artist. So instead we opted to divide the buildings in rooms with portal polygons at their entrances and windows. The room themselves are bsp based.

Some tough on engine designs

One of the best features an engine could have is seamless integration between inside and outside areas (as you may know portals are ideal for interior scenes, but a bit lacking for exterior ones. (altough when used in conjunction with an exterior engine or module, havegood results). The ultimate seamless should be if the player could be on space, go to earth, go to island, go to building on island, and go to room on building on a seamless fashion. So clearly there is room for algorithms that have not yet been tough of.

There is some tough on realtime prodedure generated terrain, building, plants , world generation. In the game area, this give the oportunity on vast worlds. This is possible (with the exception of the plants) in todays hardware, altough not as straight forward as using meshes.

Any new engine should try to take advantage as much possible of the shader hardware in the newer video cards. So its design should acomodate for them as well as hardware T&L.
Posted on 2002-06-01 12:33:53 by dxantos
I am applying my matrices using a vertex blender to perform tweening between animation frames (nonlinear keyframing) and currently am applying four layers of matrices to the animated models, so it scales well.
I wasn't intending on using the engine for outdoor scenes, but if I do decide to go to full hack and code indoor/outdoor, it will switch to progressive meshes and steer clear of BSP. I mean really, BSP is not much use either when it comes to empty space,it's more suited to a quadtree or octree engine, don't you agree?
They're best at dealing with empty spaces, the only drawback to portal engines being clear line of sight through nested portals.
This could be avoided during design, restricting the view to large empty sectors to its sibling sectors.
I don't think quake3's use of PVS (potentially visible sets) is very much different to saying "A node in a BSP now is a sector in a portal engine, what surfaces can we see in this sector?"
I think it's just a tad redundant. They're encoding all the potentially visible surfaces from each Node within that Node. Why do we need a BSP in the traditional sense if we think about a portal engine in BSP terms, as being a tree-structure containing PVS information? That's what I'm saying.
Why do we NEED to keep a BSP, if we can determine the PVS for the Node we're in without being concerned about "some" overdraw? Remember, the whole point of BSP is to figure out what NOT to draw without having to process the entire world. It's nothing more than a method of Subdividing Space. It's beauty lies in it's system of keeping the Order of surfaces in the world, to avoid z-sorting, which was the classical method of VSD (Visible Surface Determination). That beauty comes at a price. The great drawback of BSP (realtime manipulation) can be conquered, I am certain, without having to resort to old z-sorts or scary nested octree or quadtree systems. I do agree completely that Portals won't handle Outdoor scenes on their own.
Dirty Notes are at This Link
You may be interested to learn that I am not only using materials to encode portals, I am also using them to tag bodyparts within the skinned models. They contain hidden surfaces which are exposed as parts are "hacked off", we simply don't rend those materials, and we copy those vertices into an instanced object so it can fall to the ground... the demo game I am creating with the engine is an online multiplayer Last Man Standing game where you may steal and use bodyparts (cannibalistic robots) but I do include some humans which are good for target practise.
Entire skinned models can be instanced as particle arrays for blowing them up, even though the model is loaded and stored as a single skinned mesh, simply because we assume that the vertices of a bodypart are identifiable by the material of the surfaces which make it up.
Posted on 2002-06-01 14:50:31 by Homer
I would LUV Environment/Chrome mapping. They are so cool and I can just sit down and look at them for days! It astonishes me that game developers don't use it that much and its pretty quick too. I'm making a 3D engine too so that my friends and I can make a small game and I can reuse it by just adding new features. I don't see why Environment mapping cant be implemented its not that expensive in terms of CPU time. BTW I have an AMD Athlon 900Mhz and I want to see ur 3D engine so don't do something TOO computationally expensive.
Posted on 2002-06-08 20:25:10 by x86asm
As you are probably aware, environmental mapping is akin to raytracing in its resolution demands and calculus.
I perform a kind of environmental mapping in my projection and clipping to a portal surface, but as for realtime environmental mapping, that's certainly a worthy consideration... it can be faked to a degree, if we think about it ... we need to project the mirror surface along its normal, and figure out where its vertices intersect textured world surfaces, then we need to split our surface according to any splits in the world surfaces within our projected surface, and finally, copy and/or calculate texture coordinates for the split-up and projected mirror surface.
Sounds like a lot, but I think it could be handled nicely enough.
I'll add that one to my to-do list, and keep brainstorming it.

In the meantime, I am reviewing my whole notion of portals and sectors, and am considering going oldschool in my mapping of the world, by keeping the 3d map as a 2d tilemap of 3d objects which each have an object ID and a height field. Each object would itself be a sector, and rooms would no longer be considered sectors per se. The initial cull would be performed on the 2d tilemap in a similar fashion to many 3d arcade games, which "chop out" a section of the world around the player before manipulating it to suit the view. It would lend itself to a very simple 3d raised block contruction for the world editor which would make it childsplay to create new worlds.
Simple ideas are often the best.
Posted on 2002-06-09 07:51:32 by Homer
I've heard of ray tracing b4 but havent actually used it. It seems to me Environment/Chrome mapping is a fancy form of multitexturing (see whats so cool about multitexturing). Also you could do some pixel shading if possible to fake Enviro/Chrome mapping! I'm coding a 3D engine also and since u r so knowledgeable will you mind if I come to you for help? Oh ya please dont make the engine too intensive on the FPU...I onl;y have an Athlon 900Mhz :(
Posted on 2002-06-09 13:15:58 by x86asm
for exterior Quad/Octree is a good choice. And combining them with portals could give you both interior/exterior. That way you will render the exterior only when you are on it or when there is a visible portal that is visible to it. And the inverse is also true, draw the inside from the outside if there is a portal pointing to it.

I do use very small bsp for objects when I need translucency on them. That way I can do back to front drawing without needing to sort the polys every frame. (altough newer hardware have techniques for sort independent translucency using shaders that could make this unecesary).
Posted on 2002-06-09 17:30:29 by dxantos
I'll take that as a vote of confidence !! :alright:

Progress has slowed as I am becoming bogged in the physics engine (never was so good at physics :tongue:)
I'm trying to implement the kind of physics we saw once apon a time in THRUST ... multiple objects whose physics affect one another in a chain... you may have seen this if you ever played HITMAN and tried dragging a dead body around.

At the same time, I am working on the particle engine, which itself is much more relaxing for me as it boils down to little more than a self-managing linked list...familiar territory :)

I could be lazy and import someone else's physics engine, but I would derive no satisfaction from it, learn anything or be in a fit position to write a tutorial on the subject.

I am determined to create physics that are both fast to implement as well as having the "right feel".
Posted on 2002-06-10 13:53:05 by Homer
Ok guys, the proverbial expletive has hit the spinny thing.

Due to popular demand for outdoor support,
the Portal Engine has been scrapped in favor of
one which better handles large, open scenes.
My initial reaction was to brush up on OSP implementations.
While doing this something occured to me which I haven't been able to dismiss: in a world where space is divided into equal cubic subdivisions, empty space is ALWAYS mapped into your tree.
Even if this means a Node with all children=NULL.

You might be thinking - SO? And now I get to the point:

What we have described in OSP is nothing more than
your venerable old 2D Tile based map (aka arcade games) with an added 3rd dimension, stored in a linked-list (Tree).

Why not just base the map on a 3d cubic array?
Our array contains values which SYMBOLIZE a cluster of 3d geometry. This technique was used recently in the Tony Hawke skateboarding games in combination with elliptical collision detection.

I have completely redesigned the runtime and file formats for world maps as a result of this decision, but everything else can stay, so it's no big loss, just some time wasted.
Posted on 2002-07-08 10:37:50 by Homer
Just one question EvilHomer2k
Will my Athlon 900Mhz handle it? Its a Socket A T-Bird
Posted on 2002-07-08 14:25:54 by x86asm
Most definitely!
I am coding this on a 333 with ATI Rage2 :tongue:
Testing is carried out on a variety of machines and graphic cards.
I hope to be able to create intuitive display options by querying the hardware, but that's not my concern at the moment.
Posted on 2002-07-15 09:47:25 by Homer