I'm a graphics programmer professionally, and I hate using the raw APIs ;)
At home I use Horde3D, which is a fairly flexible wrapper that lets me focus on graphical algorithms and not API complexities - e.g. it only took a weekend to implement the "inferred rendering" paper on this engine.
At work I use a fairly thin but high-level wrapper, which abstracts all of the major graphics APIs but still exposes all the necessary render-states and functions in a much more convenient, flexible and portable manner.
How many of you use OpenGL / DirectX directly as opposed to
I use an engine (Ogre), mostly because I lack the knowledge to make my own. But eventually, all middleware ends dissapointing me.
I use opengl directly. The simplicity of old-school glBegin/glEnd originally "drew" me in, but the new-school VBO/IBO/Shader functionality rendered me faithful for life. :^)
(woops - edited to remove my own clearly off-topic opinion which did not belong here - sorry bout that =)
[Edited by - Whatz on July 16, 2010 2:45:34 AM]
(woops - edited to remove my own clearly off-topic opinion which did not belong here - sorry bout that =)
[Edited by - Whatz on July 16, 2010 2:45:34 AM]
Quote:Original post by Whatz
Besides, I never support microsoft's attempts to ruin perceived competition. :^|
wut? [rolleyes]
Author
Quote:Original post by Promit[...]OSG's approach to rendering is idiotic [...]
I don't mean to be pushy about this but I'd still really like to hear why you think so. Not for the purpose of being argumentative, I swear to the gods ... it's just that I'm (still, regretably) a graphics programming noob intending to use OSG in my project, and if there's anything inheritenly wrong with OSG, I'd like to know BEFORE I start using it. :)
Quote:I much prefer the designing data structures / algorithms stage of writing an application.
I'm using OpenGL with SDL to handle input & window. Is that considered standalone or w/ middleware?
I have done procedurally generated terrain meshes, bitmap font loaders & text parsing, and physics and collision detection so far I think all of those have involved data structures and algorithms.
I'm having trouble finding example code for OpenSceneGraph. The Tuto1.zip that I got from the wiki has a pretty vague description. I'm only acquainted with the concept of a scenegraph. The OSG pipeline processing diagram shows a similar structure to what I have in my program (with an extra step 'cull'): Update->Cull->Render
Quote:Original post by Red AntQuote:Original post by Promit[...]OSG's approach to rendering is idiotic [...]
I don't mean to be pushy about this but I'd still really like to hear why you think so. Not for the purpose of being argumentative, I swear to the gods ... it's just that I'm (still, regretably) a graphics programming noob intending to use OSG in my project, and if there's anything inheritenly wrong with OSG, I'd like to know BEFORE I start using it. :)
Oh god. Where to start. I suspect Promit is actually in the middle of replying to this, but it might take a few months to cover the basic problems, and then maybe another year or two if he's going into detail. To begin with it's worth understanding that there is not much 'right' about OSG anymore. (And I do literally mean that!).
OSG started a long long time ago, in a land before the time of shaders, when a 100Mhz Pentium 1 was king. Architecturally, everything in it is geared towards that level of hardware. i.e. No SIMD, No Shaders, No dynamic objects, Everything is rendered as display lists, limited texture support, forget about fancy effects etc etc.
It makes a couple of really nasty assumptions, mainly:
a) glBegin/glEnd and display lists are awesome ideas.
b) Computers are too slow to handle dynamic geometry (eg skinning). Static geometry for the win!
As such it's nigh on impossible to get it to support skinning or other geometry deformations, or rendering via shaders, geometry shaders, infact anything you will want to use in future. Some people have hacked in skinning, but it's some of the worst coding I've ever seen (not to mention extremely sub-optiomal)
Fast forward a decade or so. Over that time every man and his dog has 'improved OSG with awesome new features', such as (half arsed) support for every file format on the planet, and god knows what. Compile times are monumental, linking times are even worse, and the lib itself isn't really that good enough to warrant bothering to compile it.
The real killer though, is that if you have an extremely complex static scene, you'd be better off simply dumping all the data into a single VertexBuffer and rendering. You'll get a better framerate with that than you would with OSG.
Author
Interesting. So are there any viable alternatives? Apart from just rolling my own graphics engine? Any decent libraries that shield me from all that low-level stuff?
Ogre 3d has already been mentioned in the thread, its probably the most complete open source, free rendering engine, though everything else (I/O, sound, physics,etc) you'll have to incorporate on your own.
Current project at work uses JupiterEX (FEAR) engine. Moving to CryEngine on the next project. I haven't written much pure DirectX or OpenGL since I graduated college. I am using XNA for a commercial side project though. XNA is somewhere between pure DirectX and full game engine middleware.
As a few have mentioned above, most companies in the commercial gaming/sim world just want to build the product and ship it. They don't want to have to muck around with low level graphics/hardware stuff. Thus they license engines from other companies who specialize in the low level graphics/hardware stuff.
As a few have mentioned above, most companies in the commercial gaming/sim world just want to build the product and ship it. They don't want to have to muck around with low level graphics/hardware stuff. Thus they license engines from other companies who specialize in the low level graphics/hardware stuff.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement