As we already know OpenGL is the standard common API among every CAD/CAM software, image-video editing and rendering, not to mention video games, and other interactive applications…
However, some may choose an alternative wrapper such as a scene graph. I’m aware that a scene graph is more than just a wrapper, but this is to make sure we are not off-topic. Based on my experience working on CAD project, and at a point we had to use an engine, it’s was a management decision anyway. Since then we have been facing problems…from reintegration to instability…to inflexibility…I’m not going to criticize any engine in particular, but does it worth wasting time to get some features provided by the engine for free, while we can write our own with a little more effort?
Anyone has such a nightmare using an engine and then they decided to switch back to the more logical and practical solution?
ONE big issue was the Vista and that some hardware lacks of good drivers…and I mentioned that in different post “Under the hoods of Vista.” Again, do developers need to support the platform,or is it the platform creators’ responsibility?
Why in the first place we need to go back to DOS days and doubling rendering path-lines, for different APIs?
Do we need to support a “company,” or their platform because they want to enforce their “standards,” which are unstable and will never be?
Well, I never started to use any engine although I was considering it.
At first I developed a small library. It served me for a long time (3 years, hehe) as I’ve learnt OpenGL.
Next one pretty much the same, but rewritten for more professional resource management. I used it for less than 1 year.
This is the point where I started to look for an engine, but I couldn’t find any that would suit my needs. What I was looking for was actually a framework, not an engine.
An engine covers more layers - from basic stuff to rendering and physics.
What I wanted was some developer’s kit to build my own engine.
This is why I started my current project - FOG (Framework for OpenGL or Framerowk for OpenGL Game - I haven’t decided yet ).
It’s focused on low level stuff without defining any rendering or physics mechanisms - they’re most fun to implement on your own
If you’ve got a quick demo project or hack-n-slash one-off (many games and college projects fall into this category) to do, or some very usual or non-performance-critical task, then using someone else’s “rendering guts” may save you time/money “if” it supports everything you need to do (or can be made to without wasting too much time).
However, if you are developing and maintaining a reusable product long-term where features and performance are critical, particularly if it’s very specialized, I find that it’s IMMENSELY valuable to have your own “rendering guts” (spatial accel data structures e.g. scene graph, paging infrastructure, etc.). Yes, it takes longer to get up the first time, but then when you need to change something for your customers (features or performance optimizations), changes are very fast, and you’re not shackled to what the 3rd-party rendering guts supports (or how well!).
With 3rd party, even if you spend the time to implement the changes you need to the 3rd party guts, there’s no guarantee the maintainers will roll it into the master code base or even provide you the “plug-in APIs” you need to make it work, which leaves you maintaining a big hacked-on patch set or tightly-coupled spagetti callback/plug-in monstrosity on top of their guts (read: hard to maintain). This is one of the forces that killed SGI Performer at our company. And even if they did roll it into the base source, if it’s an open source engine, your competitors get that for free. How’s that fair? And even if it’s not open source, you have to wait for releases from another company to add support for your new feature. They’re pleasing other customers, not just you, so it may be a while before you see that shiny new release you need (leaving room for competitors to get the jump on you).
So custom rendering guts can reduce your turn-around time and costs once you get going with it, but whether they will or not depends on the specifics.
Have talked to a few game developers that do dev on the Unreal engine, and their biggest gripe is that hacking and slashing the locally-bastardized copy to the virtually uncommented Unreal engine is the biggest pain in the butt. But whether it saves them time or not, I don’t know.
So basically, it’s a cost/benefit analysis. Keep track of how much extra time/effort you’re spending hacking around the engine you’re working with as compared to before when you had your own. Consider the cost of labor (game shops throw new grads to hack-n-slash for peanuts; other industries, more experience, less chaotic). Was it highly specialized work before and now you can throw new grads at it? Are you missing deadlines for comparable work whereas before you weren’t? Are your tasks incremental improvements built on each other in a long-term product and thus need designed and implemented sanely, or are these one-offs you cast off every so often so a plug-in/callback monstrosity might actually be reasonable?
It is naive to assume that any software you implement yourself will be bug and problem free. Scene graphs vary in quality and have different design goals, some are crap and written by people you don’t want near your graphics code, others are impressive in scope and implementation. You might want to try Open Scene Graph, it’s free (as in beer and freedom) and I hear it’s OK.
As for supporting platforms, customers want solutions and pay for them. They don’t pay you to throw software over a wall at them and ask them to sort it out. Applications can leverage middleware but in doing so they own the problems it creates. Additionally applications often have errata and workarounds related to underlying graphics drivers which are uniquely complex as drivers go, many applications have certified drivers that are specifically required to run them with no guarantees related to other driver releases, with high end professional software this approach is essential to manage bugs, wayward driver updates can ruin your weekend.
It sounds like you’re not on board with the decision to use middleware. I suggest you try to understand the benefits it brings and the skills you would need to solve the problems it does, however it is always possible that it has been chosen poorly.
It rather depends on how widely software has been used before and how complex it is.
In other words - I haven’t written my GeForce’s drivers myself, but that didn’t prevent them from allocating 2GB of memory and crashing during shader compilation GLSL was a new feature back then, therefore not widely used, and graphics driver is a complex software.
Anyway, I totally agree with Dorbie and I’d like to add that if one goes for 3rd party software, he should always prefer open source. This way, if he runs into a bug, he has the ability to fix it himself and continue development rather than implementing temporary workaround and waiting for bug to be fixed. Error should of course be reported
Same goes for adding some specific feature to that 3rd party software.
Therefore I think Open Scene Graph is most recommended - it’s well known and allready used in many applications therefore less likely to contain serious errors.
NVIDIA’s scene graph is also interesting - you may expect it to be/become well optimized for NVIDIA hardware. I think this is a good choice for companies providing their customers with both software and preconfigured hardware.
and I meant Ogre3D engine which is twisting our arms in many different ways. and until it’s too late to change the decision, we discovered it’s a merely a single-window static geometry engine, other than this it’s a nightmare.
I have never used OpenSceneGraph, but I guess we will face the same problem since it’s graph-based rendering.
Even for simple text, we had to write our own engine to support 3D text rendering, and it takes for a string, a node for every character and a mesh clone for every glyph. what a pain and slowness.
My personal experience with Ogre3D was that way to many classes are singleton for no reason at all except perhaps that the Ogre3D developers like the design pattern
What I’m trying to say: Ogre3D is great if you want to do exactly what the developers of Ogre3D had in mind when designing the engine. The design is very consistent and easy to use, but it’s very inflexible.
OpenSceneGraph is in that regard the exact opposite: It’s very flexible, you can extend almost everything you can imagine, and it was designed with high-end systems in mind, so it runs equally well on a single machine as well as on rendering clusters and VR installations.
Of course this flexibility comes with a price. For the average game developer that doesn’t need all those fancy features, OpenSceneGraph is a bit harder to use than Ogre3D.
).
GLSL was a new feature back then, therefore not widely used, and graphics driver is a complex software.