Message Board
| Message Board > C/C++ > writing a graphics engine |
| January 20, 2011, 04:54 | |
|
joebeard
Bearded 9 posts 
|
Hi everyone, For the last few months before Christmas I was writing a terrain engine prototype in OpenGL using C, and a few classes here and there from the C++ standard library. I hadn't really committed to any particular engine structure or class hierarchy, intending the prototype to be my little exploration into the world of graphics programming. At the moment I'm at a bit of an impasse - I began to burn out spending so much of my time programming (my RL job also involves programming, but in a much more horrible language - AS3) so I took the month off. Well now it's time for me to get back into the swing of things. I left off having almost implemented vertex buffer objects in my terrain renderer, the engine uses clipmaps to handle massive landscapes at a fairly high speed, and height at any given point on the terrain is calculated from a noise texture on the GPU. I had plans to add HDR (including atmospheric scattering) and shadowmaps, and then to bend the whole thing over a sphere to create a planet, but there's one thing stopping me: My code is a bloody great mess. Seriously, globals everywhere, the only thing that keeps it together is my dubious use of namespacing. The reason I kept everything open was that again, I was building a prototype - a little space for me to muck about with shaders and other things and to get to grips with graphics programming. Now the time has come to sit down on some lunch breaks and sketch out an engine, to figure out a robust rendering model that will allow me to produce an arbitrary number of planetary landscapes with realtime lighting, atmospheric scattering and anything else I might care to include. Preliminary ideas from reading stuff around the web and from stuff I learnt at Uni seem to point to a data driven approach: I conceive my engine as a set of transformation functions operating on streams of data. This makes sense for a graphics engine (though not necessarily for a game engine, but I'm really only interested in physics and graphics), and further exploration of the idea yielded a very sketchy concept of attaching tags to chunks of data, and throwing them into a stream which is then worked on by the graphics engine. In a human readable format my tags might resemble network data packets, with a header describing states to set or unset on the engine, and what modules to load / shaders to use / LOD methods to use for the graphics data that will follow. Some of the advantages I see to the method is its client / server approach which sort of mirrors OpenGL's approach (the API I will be using), and being able to pass the stream of data through an optimiser or other transformation (e.g. LOD) functions, and its modular approach which I tend to hold higher than OOP practices. tl;dr: Have any of you written graphics engines or other applications that operate on streams of data, and if so (and even not if so), would you care to share any thoughts on my gigantic wall of text? Oh, and here's a pretty little picture from my prototype, which has also horribly scaled this page, my apologies:  I added fog to give a better impression of depth (it also looks like something from 1998 but oh well), which detracts somewhat from the huge view distance, unfortunately scale is hard to demonstrate with such crappy textures and a very basic noise function. ____________ Enjoying a lovely evening with Sander Cohen |
| # | |
| January 20, 2011, 15:08 | |
|
FredBlaster
Gagalicious 22 posts 
|
Pretty. but don't come back until you've got normalmapping working. j/k 
____________ |
| # | |
| January 20, 2011, 17:40 | |
|
Eckolin
Quite Whiskered 388 posts 
|
Remaking Surreal outdoors, eh?
____________ Maker of Games... Wisdom is supreme; therefore get wisdom. Need help with coding? I probably wrote something similar. |
| # | |
| January 20, 2011, 19:39 | |
|
FredBlaster
Gagalicious 22 posts
|
i expect to see the hacking engine/interface and cut scenes implemented  :p
____________ |
| # | |
| January 21, 2011, 00:27 | |
|
joebeard
Bearded 9 posts
|
Surreal was just an arbitrary name, the second version will use marching cubes instead of heightmaps to draw terrain, which will allow me to create some crazy fully 3d (instead of heightmapped) terrain. The marching cubes algorithm is solid though, so I don't expect to be doing that any time soon. I managed to fix my VBO problem, it was a typo in my code that was causing me to re-assign vertex buffer objects as index buffer objects... How anything ran at all in the first place is a mystery to me. It also runs like a pig on my windows 7 work station, but very fast on my old winxp rig at home, always knew win7 was just as shite as vista. I think vista+ emulates opengl in d3d anyway... Back on topic, any discussion on the whole graphics engine concept would be welcome... [Edited on January 21, 2011 by joebeard] ____________ Enjoying a lovely evening with Sander Cohen |
| # | |
| January 21, 2011, 22:49 | |
|
Sandman
F3n!x0r 1194 posts 
|
I've only fiddled with OpenGL up to 2.0, nothing fancy, no shaders. I've also tried Horde3D for a bit, which is a graphics engine. They employ a sort of tree to identify when what should be rendered. I don't know the intrinsic details though, but you could have a look at the source to see how they tackled this. Good luck, already looks cool. Next picture needs dynamic shadows! ____________ BennuWiki Yes, my avatar has grey borders in IE (so get a decent browser) ROOFLEZ ROOFLEZ |
| # | |
| February 1, 2011, 13:00 | |
|
Dennis
どこかにいる 2092 posts 
|
This looks awesome so why be so modest about it?
____________ Kwakkel |
| # | |
Message Board > C/C++ > writing a graphics engine