3d engine design, want comments
Author
Hello, I'd liek to write my first 3d engine. Here are a few specs I can think of
Direct3D 9, just basic lighting & textures (no shaders, just the fixed pipeline), basic keyframe animation, camera, hierarchy system. Would also like to implement some sort of kd-trees.
the idea...
create a hierarchy, each node would be a a class derived from some baseclass (say CSceneNode) so that rendering of various types of meshes/billboards etc could be done. Each node would contain a transformation matrix and it's children would be transformed relatively to their parent. Cameras and Lights would be nodes too, so that they can be "attached".
The scene manager would keep track of the active camera.
Each node would have a AABB so that it can easily be classified as in-frustum or out-of-frustum (since frustum is basically 4 line segments, that would only take 4 box-line intersections, which is pretty fast. A node type that would further divide itself (kd-tree, or an octree) would also be present for some complex geometry.
what do you think? I've never done anything, but let myself be a bit inspired by the IrrLicht design.
The design sounds good, not ground breaking but should be functional ;).
Take care here. A frustrum is usually made of 6 planes (up, down, left, right, near, far), not 4 lines.
Quote:Original post by Caesar
Each node would have a AABB so that it can easily be classified as in-frustum or out-of-frustum (since frustum is basically 4 line segments, that would only take 4 box-line intersections, which is pretty fast. A node type that would further divide itself (kd-tree, or an octree) would also be present for some complex geometry.
Take care here. A frustrum is usually made of 6 planes (up, down, left, right, near, far), not 4 lines.
Quote:Original post by Caesar
Hello, I'd liek to write my first 3d engine. Here are a few specs I can think of
Direct3D 9, just basic lighting & textures (no shaders, just the fixed pipeline), basic keyframe animation, camera, hierarchy system. Would also like to implement some sort of kd-trees.
the idea...
create a hierarchy, each node would be a a class derived from some baseclass (say CSceneNode) so that rendering of various types of meshes/billboards etc could be done. Each node would contain a transformation matrix and it's children would be transformed relatively to their parent. Cameras and Lights would be nodes too, so that they can be "attached".
The scene manager would keep track of the active camera.
Each node would have a AABB so that it can easily be classified as in-frustum or out-of-frustum (since frustum is basically 4 line segments, that would only take 4 box-line intersections, which is pretty fast. A node type that would further divide itself (kd-tree, or an octree) would also be present for some complex geometry.
what do you think? I've never done anything, but let myself be a bit inspired by the IrrLicht design.
So you basicly have a bounding volume- & transform hierarchy. Sounds like basic scene graph design. Nothing wrong with your ideas, although as b34r said the frustum can't be represented by 4 line segments.
I agree with those above. A very good project; to get a scene graph up an running with some basic culling.
Using that you can then continue to expand/modify it as time goes. Adding whatever you want.
One thing that I think is good if you want to develop an engine is to use it in a real project. That is after you have some basic functionality you use it for something real (not just a tech demo). I always gets surprised when my elaborate engine designs turn out to be completely unnecessary and overly complex :P
Regards and good luck!
/hObbE
Using that you can then continue to expand/modify it as time goes. Adding whatever you want.
One thing that I think is good if you want to develop an engine is to use it in a real project. That is after you have some basic functionality you use it for something real (not just a tech demo). I always gets surprised when my elaborate engine designs turn out to be completely unnecessary and overly complex :P
Regards and good luck!
/hObbE
Author
You seems to point out that there are also other ways to take in designing a 3d engine. Like what kinds of?
Yeah, I was wrong with the lines. I was imagining the 4 lines that connect the near and far plane... somehow, the other 8 or the possiblity it need not intersect any of the lines and still intersect the frustum came on my mind. How should I do it then? Check plane/box collisions or is there a completely different way?
Also, would my design allow shadows later (no idea what kind of shadows I'd do, probably any would be good enough) or would it be hard to implement them?
Yeah, I was wrong with the lines. I was imagining the 4 lines that connect the near and far plane... somehow, the other 8 or the possiblity it need not intersect any of the lines and still intersect the frustum came on my mind. How should I do it then? Check plane/box collisions or is there a completely different way?
Also, would my design allow shadows later (no idea what kind of shadows I'd do, probably any would be good enough) or would it be hard to implement them?
Quote:Original post by Caesar
You seems to point out that there are also other ways to take in designing a 3d engine. Like what kinds of?
There are no rules on how to design a 3d engine. BTW, when you say 3d engine I assume you mean the stuff you need to be able to represent a 3d scene and render it efficiently.
You should be able to organize scene objects spatially in order to make various spatial operations such as frustum culling and collision detection more efficient. This was my approach when designing my 3d engine, so I designed a generic datastructure that took care of this. I'll worry about transform- & render-state hierarchies later. I'll find out soon enough if this was a terrible mistake or not.
Anyway, I can recommend that you try immitating the design every other engine uses and find out for yourself what you want to improve (if anything). Immitate then innovate is a good expression that also applies to 3d engine design.
Quote:
Yeah, I was wrong with the lines. I was imagining the 4 lines that connect the near and far plane... somehow, the other 8 or the possiblity it need not intersect any of the lines and still intersect the frustum came on my mind. How should I do it then? Check plane/box collisions or is there a completely different way?
Yes you do intersection tests on the box and the 6 clipping planes that represent the frustum. If the box is behind any of the clipping planes then the box is definately outside the frustum. Otherwize the box intersect or is inside the frustum.
Quote:
Also, would my design allow shadows later (no idea what kind of shadows I'd do, probably any would be good enough) or would it be hard to implement them?
I don't know shadowing works so I can't comment on this.
Author
Thanks you all. I'll try to implement it the way I've described then. You've been very helpful
Also, you'd need to define the scene structure for your engine.
Scene graph nodes don't cover all aspects of an 3D engine, as objects interactions, neighboring, physics, collision detection and visiblity culling.
At first think about if you want to implement large outdoor landscapes, or an indoor complex like Quake buildings. How you might distribute sceneary for help your virtual characters walk through?
Keep a Sector-Portal structure is an strategic option, not only for rendering, but also for Collision detection and AI. Virtual characters will be wise when you provide them paths for navigating through the world, and they will be able to find doors and windows for move between rooms.
Scene graph nodes don't cover all aspects of an 3D engine, as objects interactions, neighboring, physics, collision detection and visiblity culling.
At first think about if you want to implement large outdoor landscapes, or an indoor complex like Quake buildings. How you might distribute sceneary for help your virtual characters walk through?
Keep a Sector-Portal structure is an strategic option, not only for rendering, but also for Collision detection and AI. Virtual characters will be wise when you provide them paths for navigating through the world, and they will be able to find doors and windows for move between rooms.
Author
Quote:Scene graph nodes don't cover all aspects of an 3D engine, as objects interactions, neighboring, physics, collision detection and visiblity culling.
At first think about if you want to implement large outdoor landscapes, or an indoor complex like Quake buildings. How you might distribute sceneary for help your virtual characters walk through?
I was thinking I'd keep a separate copy of the geometry in memory for collisions, since accessing it from vertex buffers might be expansive. Although this is going to be memory-expansive, but have no better idea.
Quote:
Keep a Sector-Portal structure is an strategic option, not only for rendering, but also for Collision detection and AI. Virtual characters will be wise when you provide them paths for navigating through the world, and they will be able to find doors and windows for move between rooms.
haven't thought about that yet. Sector-portal: do you mean having each "room" as a polygons and doors marked by a sort of waypoints? Or just waypoints? Wouldn't that make them even dumber then, why 3d at all when they only move on lines between waypoints...
I was primarily thinking of doing it just for rendering. But this is an aspect I should keep in mind, I agree. That's why I haven't decided yet if it's going to be used for outdoor or indoor scenes... and haven't thought about AI yet.
Sector can viewed as an island where objects are treated separatelly from another island (sector).
A sector can be conformed by a group of objects that are render together. They can be organized in a KD-Tree structure if you want, but it isn't necessary.
That sector have doors or portals that give a view to more sectors, and you can implement a occlusion test for check objects visibility. That helps if you want to draw a large world.
A sector can be conformed by a group of objects that are render together. They can be organized in a KD-Tree structure if you want, but it isn't necessary.
That sector have doors or portals that give a view to more sectors, and you can implement a occlusion test for check objects visibility. That helps if you want to draw a large world.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
