Sorry your browser is not supported!

let me start by saying I know how much work is involved! I have a good knowledge of how matrices and vectors work in an api. I know and have written small programs in openGL and understand the render pipeline. With that being said for educational purposes I would like to write my own 3d engine. Most likely it will never get finished. But I think I will be able to do a much better job on my current and future projects in DBpro and programming in general as I will understand the lower level workings of things much better. This also will not be the only thing I will be working on. Before I start diving in to coding I would like to know if anyone here has any tips or pointers that could help me. I would like the engine to do the following(probaly unrealistic but):

1.)have its own file format(have code for this)
2.)have some kind of frustrum culling and possibly octree(still figuring out how to code it)
3.)have someway to make a terrain probaly by means of a heighmap
4.)If I get far enough I will write a python script in Blender to export to my engines format
5.) lightmapping
6.)LOD or level of detail on certain objects like terrain by means of texture filters and mipmaping
7.) multitexturing
8.)dynamic lighting,shadows and reflections(by means of the stencil buffer)
9.) curved surfaces
10.) fog and particle engine
11.)antialiasing

Thats enough for me to work on at the moment I think
IF any of you have suggestions that be great. and dont flame me as I think I clearly stated my reasoning over why ive embarked on such a project and Im sure there are some openGL or Directx programmers somewhere on these forums.any ideas would be great.

I helped with a project a while back when Gamemaker was in version 4.2 i think. A guy named Freegadgets made a 3dish doom game with gamemaker, adding a fake z axis. Its was really all sprites turned to face a camera object with lots of coding. no DLL's though.

This was all on wolfdreamers forum.

I helped make alot of examples including a stair and terrain example with actual polygons in a 2d turned 3d engine.

Wolfdreamer lurks around here from time to time .

By writing your own 3d engine, do you mean writing a software engine where you code every single function yourself, or do you mean building on top of an api?

If you mean writing your own software engine, I've written a basic one myself, so I could point you in the right direction if needed. If so, I wouldn't recommend sacrificing too much time for a software engine, considering that more advanced features can be really time consuming to get right and wouldn't really aid in your understanding of how to work with commercially competitive apis (directx, opengl). Implementing the fully functional basics however is definately worth it.

As Whisper Wind has said, there is a huge difference in writing a DirectX or OpenGL based graphics engine to writing a software based graphics engine.

If you are doing this just for educational purposes then probably you should be thinking about a software based engine, one where you do everything yourself, otherwise, you're just learning an API not the fundamentals of 3D programming. Sure, you'll get better results faster but in the long run you are better off knowing what is going on (or at least having a good idea) under the hood.

You will learn loads by doing it as nothing is abstracted from you, you will see it all for what it is, and I can tell you that its a fascinating journey.

However, the feature list you gave was pretty advanced, to say the least, and would probably not be worth the effort for a software based engine as even if you did it all perfectly, using C++ and ASM it would still be slow and not even compare to some simple DX based effort that took half a day.

You have to remember that doing it all yourself, in software, you have to go back to the early days of 3D and follow what the pioneers did.

You will have the advantage of a much faster PC with tons more memory but even doing something as "basic" as perspective correct texture mapping is very hard, and fraught with optimisation problems that need to be overcome. It took the experts years to get it right, and when they did, they committed the routines to the hardware Graphics cards we use today.

On my website you can find some demos of stuff I've made with a DX based engine (The engine is written to the DX API) and 3 sofware renderers, one in Javascript(!!), one in C# and one in Java. In all cases the engine was designed as a wireframe renderer although I added dynamic lighting and filled polygons later on.

In my case, I stumbled when it came to implementing a proper ZBuffer (I used the painters algorithm), a scanline renderer & texture mapper. Although I know the effort that went in, it still looks like cr@p compared to any DX program, although it boasts its own file format, scene managements and collision detection / response.

Although its hard, time consuming, and even if it goes well, will look like cr@p compared to anything remotely contemprary, if you want to learn 3D programming, then I couldn't recommend it enough! I would even go as far as to say its an essential excercise, as DX abstracts so much away its easy to "lose track" of what its doing for you, so you'll end up with no idea how to optimise, or how to achive certain things.

My advice, if you really want to learn this, would be to start off by writing a wireframe engine, and see where you go from there.

There's a brilliant tutorial around from a chap called Simon Brown that provides an excellent introduction to this, and its wriiten in a very easy style for those who are just starting out.

http://www.sbdev.pwp.blueyonder.co.uk/intro.htm

Have a go, its good fun, like he says on his site..



THAT'S the empowerment, right there.

From just being able to plot pixels (or draw lines in the case of wireframe) you can write 3D programs!

Hurrah!

Question: Why reinvent the wheel? Why not spend this time using an already made engine to futher the project you want to do in your engine you'd like to make?

I wrote one called Dark Basic. I got screwed over because I didn't read a contract I signed with some British convicts... I showed them by writing the WORST IDE EVER!!!!


You'll learn a lot just by working on your own games. I've learned a great deal myself. If I'd been messing around with my own 3D engine, I wouldn't have a thing done. I just believe that my own 3D engine wouldn't be as good or complete as DBP, so I'm very happy to be using it

Well, for a start, if you write your own engine, you can include features that are unavailible elsewhere; e.g. Geomod, Voxel type rendering etc. etc.

Its also a great learning experience.

I think the current vogue of round wheels is vastly overrated.

Sega had it right with the cars in Virtua Racing when they introduced the "Hexagonal" Wheel. I believe Honda are running trials with their version for the 2007 F1 season...apprently grip and speed are far improved, almost to DarkPhysics standards, although the driver can suffer from something called "Vibration Sickness" (VS).

http://www.f1.com/news/Aug06_HondaInventSquareWheel.html



But seriously, I think the answer is just because its fun to find out how things work, how that X model you load in turns into the 3D object you see on screen. In doing so you develop a far better understanding for the underlying principles and allows you the insight to solve problems later on.

For example, when I worked in Direct3D I struggled with the (lack of) concept of a "camera". I didn't know how to solve it, my high level thinking just said "I need a camera object!".

So I went onto google, found some C++ code and converted it into C#. It worked, job done. But because I didn't really write it, nor fully understand it, I found it diffucult to modify. I didn't feel totally in control.

After writing a sofware engine, I knew exactly how to implement a camera, and did so in a fraction of the code I'd used before. My new camera was also flexible and could be applied to objects as well, and was far simpler to use. It could be floating or attached to something else in the 3D world. Objects could become cameras and vice versa.

Doing this also gave me insight into how objects could connect to each other to create a heirarchy where moving the parent affected all its children (like our boned x models).

From this grew a scene management structure which enabled me to write a "platforming" engine when an object could stand on others and be carried along/rotated and then jump off onto another.

Basically, the knowledge gained from doing the basics led onto more and more and more. Before I knew it I could do more (functionally, if not visually) in Software 3D than I had ever been able to using DirectX!

There is also a practical reason for software 3D.

It is lightweight and portable and does not rely on any special hardware at all, no drivers are needed, etc etc. This makes it great for the web, where your user may have a client using a Mac or linux or any kindof windows configuration.

Using Java, you can deploy to these platforms and in most cases the user doesn't even have to install anything. It runs in software so causes no security problems with installation or hardware access.

So the advantages are two fold:

1) You can bring 3D to any program you write, ever, including those for mobile devices.

2) And when you do get the graphics on screen you will find you can do much more with them. You get to be the master.

Wel originally in my post I meant a 3d engine built up off the openGL api.But I have writen a software renderer before. I first prototyped the algorithms in DBpro then ported it over in C++. note that the dbpro 1 ran extremely slow as the 2d line commmands get to be scary. I quickly stopped trying in DBpro due to many problems I had. So for about 2 months I wrote a simple wireframe software renderer in C++. I learned much from this as matrix math and vector math became something of second nature. I never could get texture mapping ever to work but I did have some simple routines for basic vertex based lighting. I know I could have taken it further but I think I gained enough knowledge I needed to work on my project.THe thing is I had a great time actually coding my software renderer and I actually wish I could have done more.I might take it up again. But at the moment Im looking to move forward. Actually the idea for a software renderer actually came when I was on an airplane I was using my pocketpc with pocketc and gamewrite on it. I was playing a game and I was thinking what if I could program 3d games on my pocketPC that would be really cool! So I worked a litle while on setting up a library to do vector and matrix operations and thatz what got me intrested in lower level stuff. Never finished that 1 though.So that all being said I want to step up to openGL now and see if I succesfully apply what ive learned to create a 3d engine in OpenGL that has some basic modern day features. after I do this I think 3d programming in general should be much much easier for me when I step back up to dbpro and other game engine SDK's.Kind of make sense?

Perfect sense.

So really I think you're asking if anyone has tips on implementing (items from 11 point list above) in particular using OpenGL.

Not sure if they cover that sortof thing at Nehe?

pretty much. funny you mention it thatz were I learned openGL. ive read many of there tutorials.Most of them were really good. Ive got an idea of how to do most things. but such things like octree im finding hard to get my head around. I understand the logic but organizing my code to render that way dynamically is something I have to think about. So rather what im asking is for some tips on keeping on anything from organizing code to implementing certain features or even some good tutorials or books on some of the more advanced topics.As many engines im going to make it function based most likely.thanx for your help!You seriously got me thinking about taking up my software renderer again vr2.

Well not that surprising since I think Nehe is #1 OGL resource on the web?

As for books that talk about octrees + stencil shadows, I remember getting good stencil info from a book called "Game Coding: Complete" which I think is in second edition now. If you want a tip, you can use their method, then research on "Carmack's Reverse" to alter your code to get the perfect Stencil Shadow.

Another tip is that I found that generating a shadow volume creates ALOT of extra vertices, and this slows things down if you've not got HW Vertex Transformations.

Here's a screenie using a vastly simplified mesh to create the shadow:



Not sure but I think maybe vertex shaders are used to do this nowadays?

Fragment shaders.

Aha, okies, my bad.

So, what do you do with them, do you just say "Load in this fragment shader called *CreateShadow* and apply it to the car"? I've only recently got a PC capable of running Vertex & Pixel shaders so I'm pretty green about such things!

I guess that newer HW would be required on the client to enable such things but as I said, I found stencil shadows quite slow anyway, too slow to be used anything but sparingly at best.

Thanx for the help you guys! I looked at that tutorial on software rendering for the heck of it and wow was that easier to understand,lol the one I read through some paper on matrices there uses etc. but it had no code or pseudo code. didnt show the filling of polygons etc. Im actually tempted to continue on the project for my pocket pc with the software renderer and stuff alongside with my dbpro stuff. Anyways thanx for all the help! i havea feeling its a long rode which ever direction I go in but im sure it will be worthwhile. THanx!