This project is read-only.

A little confused

Feb 7, 2012 at 11:15 PM

I think that this project is cool, but I am not really sure where it is headed. After I looked at the front page of the project, I thought that it would be a library that wraps Opengl. I downloaded the most recent snapshot (12219), and I became a little confused. It seemed that it did wrap it, but it had lots of extra stuff, like scene building stuff. It looked cool, but I thought that this would be more like a wrapper as opposed to Maya. All I really need is OpenGl.cs, OpenGlControl.cs, OpenGlControl.xaml, and Win32.cs stuff, along with the initialization stuff. I am just saying it is cool, but it comes with too many extra "features". Any comments?

Feb 8, 2012 at 10:03 AM


You've hit the nail on the head with regards to the current version of SharpGL. The issue is that most people need only the OpenGL wrapper stuff - fewer people need the scene graph. However, some tasks will be common in many apps - loading polygon geometry, managing materials/textures etc, which is where the graph comes in useful. However, the Scene Graph almost forces you to be making a maya type application, as it has all sorts of functionality to do with manipulating objects etc etc. I'm currently working on breaking it out so that there will be:

SharpGL.Core - OpenGL wrapping and controls
SharpGL.SceneGraph - Core scene graph elements, polygons, materials, textures etc
SharpGL.SceneGraph.Design - Elements of use if creating maya style applications
SharpGL.SceneGraph.Game - Elements of use if creating games

These will be separate assemblies so that developers can pick and choose what they need. Too many of the features of SceneGraph are only needed in very few circumstances, so I'm in the process of generalising it so that it can be a baseline that can be adapted to your needs, for example, in the latest version you can create your own 'SceneElement' objects, which are just things that participate in the rendering process, then you can implement specific interfaces to determine their functionality, for example:

IRenderable - If this interface is implemented on a SceneElement it will be rendered.
IBindable - If this interface is implemented, the SceneElement has a 'Bind' function which changes the state (e.g. Lights are bindable, but not renderable)
IVolumeBound - If this interface is implemented, the SceneElement has a known bounding volume which can be used to support hit testing, raytracing optimisations etc.

Then there is also the concept of 'Effect' objects - an effect sits at a point in the scene tree and pushes effects onto the stack - an effect might be a linear transformation, volumetric fog, pixel shaders etc.

However, all of these interfaces can be implemented on your own objects (if you desire) so that you can build your own functionality.

Also, in the new version, you can mix and match - if you have a pure 'standard' OpenGL application, but you want to use the SceneGraph Polygon (say to load data from a 3D Studio Max file) then you can, and simple render it yourself.

Let me know if this makes sense - SGL 2.0 will be out very shortly so I'd like to make sure that it will be in the direction that people will find useful! 

Feb 8, 2012 at 1:50 PM

Ok yeah that helps a ton. I think the "Effects" will be pretty cool. You answered my question! Thanks alot, can't wait tell 2.0 comes out!

Feb 8, 2012 at 2:15 PM

Yes it's going to be great - the Effect concept is a pretty important one, because it abstracts away a lot of the application specific stuff you'll need to deal with - so for example, if you want cel-shading in sharpGL, previously it'd have to be coded in the Scene object, bloating it with functionality that few need. Now you can great a SharpGL.CelShading library that has a Cel-shading effect, and just apply it if you want to - and effects can be just about an anything, so there's great room there to write your own :)