Hi all, i'm a member of a group of students out to make a game. our aim is to learn and hence we are doing most of it ourselves and not using someone else's code. we recently decided we'd make a bsp rendering engine. during the course of my small 'research' along with a few of my friends here i came across a lot of tutorials about portal and bsp rendering engines. these were extremely helpful (thanks to all the great guys (n gals ofcourse) around who make tutorials just to help others). we could understand the algorithms but now before we set out to actually code something we'd like to know things like 1. how to structure our engine. 2. what are the various things that we actually need to code. 3. since we are beginners we'd also like to have some idea of what we'd be coding and how we can plan out our engine before we actually code something. there must be more but i don't know what else we have to know to start our engine. thanks pals. Evil Smile PS: we're using openGL as the rasterizer (and we're newbies here too) Edited by - EvilSmile on February 17, 2002 3:04:26 PM

I would suggest you all take a look at NeHe''s tutorials (on this site). You will need to build:
a mesh loader
a texture loader
a renderer
a library of vector and matrix functions
a library of functions to read input from mouse, keyboard and joystick/pad
and probably functionality to support linked lists.
Once you have these you are ready to get started on the hard bits like working out a structure for the game code. You sound like a right beginner so might I suggest you buy a copy of OpenGL game programming by Dave Astle and some other people who run this site. Its a great book for beginners, jumps straight in to making an actual 3D game and will save you lots of headaches trying to figure out how to do things that everyone else knows how to do already. They didn''t even pay me for that plug, either. cheap gits.

-

Geocyte Has Committed Suicide.

Hi all,

thanks Fratt, i thought u were kidding, then i realised that it made a lot of sense to first think about what we need before we go about doing something about it.

thanks geocyte,
i'll definitely look into this.

and i am still watching this forum so neone giving me any info is always welcome.

thanks again

EvilSmile

Edited by - EvilSmile on February 20, 2002 2:14:26 AM

I recommend you jump right into it. No amount of theories will help you. 3D engine consists of million little interconnected parts that are impossible to fully comprehend. Your data structures will change as well as other code as your''re coding because you''ll be discovering new ways to do things that will invalidate the old code structures. You need to realize there is no right or wrong way to write code. However your goal is to make the game efficient as possible given your preference. If it''s fast enough you don''t need to optimize for speed.

A 3D engine will need an editor. A way to load the editor files into the engine. Data structures holding your geometry data. A possible visible set or spatial trees to limit geometry you can process. Way to parse/handle entities from 3D file. A matrix/vector/collision library. Sound/input library. Don''t go all out with the libs either, put in things you really need for this version of the game. You''ll need to deal with dynamic geometric objects. A way to cull out outside(terrain) when you''re inside a building and vice versa.

What I would do is get your 3D geometry file loader working first. So that you can look at things and can judge how big a speed hit you''re getting. There is no reason to have pvs/bsp/octree if you''re game isn''t very big. Today''s hardware can process 20k or more of triangles by brute force. Even more if using vertex/index buffers and dma + 1ghz+ cpu

So, decide on the size of levels you''ll be dealing with and everything you want to include in a level. Once you know this then start thinking about getting that 3D file into your engine. If you need to manipulate geometry then you need to build vertex data structures and push them through your cpu. This goes for multipass rendering also. After you have that done, think about collisions and lights/shadows. The most important thing is to actually have something to show for your work right away. Motivation will be deciding factor on how far you and your team will take your work. When motivation dies your project dies because it will then become ''work''.

P.S. Look into STL and learn to use map/list/vector containers and other stl stuff like the algorithms and functors. They will speed your development a bit but only when you understand how to use them. Don''t be afraid to look into stl source code either. I''ve found two bugs in vc++ 6 stl inside mem_fun1_ref_t class. It won''t work with references to objects with member function taking in one argument. You can look at mrgamemaker message board to see how I''ve fixed that so it would work.

ForgEd3D world editor

Something that you should know about bsp/oct trees. They''re only used for static geometry. Updating the tree each frame would be too costly. It might be ok for small levels though. Bsp trees cut up the existing geometry and classify it with respect to the plane that cut them up. Which means that your 3D geometry will further be split up by these planes. Once that is done you''ll need to issue new texture coordinates. I''ve seen some use bsp for collision detection by not splitting the polys but including them under the plane that split them. Same for octrees. Then again, if you have 100 rooms max in a level the cpu will iterate through them all and do containment tests(i.e. collisons) faster than you can blink your eye providing you use axis/object aligned bounding boxes or spheres or something similar. I do object picking in my editor only on those rooms that are inside or intersect the camera''s frustum. So I cull away most of geometry right away. I then sort polys by texture before rendering my texture groups. The ray/object code is very fast including poly/ray intersection point containment. Collapse everything to lower dimension then do further tests. Real-time rendering book has lots of stuff on collisions and fast algos.