[of-dev] scene graph

arturo castro arturo at openframeworks.cc
Thu Jul 2 09:20:06 PDT 2015


no push/pop in immediate mode barely exists in any real code but even
with that is much simple to think in terms of transforming the object vs
transforming the world and that's what a scene graph gives you compared
to global transformation calls.

p5js is much simpler in syntax than three.js but that doesn't mean that
the model to reason about 3d is simpler in proccessing/OF/cinder/p5.js
vs unity/three.js i think the prove is how much more complex stuff is
out there in 3d in those platforms compared to tools that somehow
inherit from processing or opengl's legacy immediate mode. Also 3d
software works like that so when importing assets it's much more natural
to work with a scene graph than immediate mode.

there's surely some functional paradigms to be used for several things
but the example you point out seems very oriented to solving a very
particular case in a very particular environment (svg/dom) no?

i really think we've got so used to immediate mode that it's difficult
to think in other ways but it's really so much simpler to reason about
things when you think in terms of transforming an object instead of the
whole scene. I haven't used any of the global transformation functions
in the last few projects and things become so much simpler to solve. i
remember trying to solve some problems using global transformations that
took me ages and when using ofNode you solve them in a few minutes.

i'm not saying we should completely remove global transformations or
immediate mode right away but if we do any advanced optimizations they
should happen in a scene graph, trying to optimize immediate mode
internally as if it was an scene graph is only going to create a super
messy architecture and is not really going to optimize much.

having a scene object and a couple of more complex materials (with
textures, different shadings...) would make optimizing so much more
straight forward than it currently is.

On 01.07.2015 21:15, Kyle McDonald wrote:
> i think part of immediate mode vs. scenegraphs is about how nested your
> transformations are.
> 
> if you don't have any push/pops in your code, it's easier to think about
> graphics in immediate mode (i'd rather teach a beginner p5.js than
> three.js). but once you get one level, or maybe two levels of push/pops,
> scenegraphs are much easier to reason about.
> 
> i'd argue there's another case, where you have many objects, multiple
> levels of transformations, AND the scenegraph is changing dynamically.
> three.js isn't very good for this in my opinion, but d3.js has a
> different approach that works really well. mike bostock calls it
> "joins" http://bost.ocks.org/mike/join/ and i don't think it's immediate
> or scenegraph exactly, it bears more similarity to xpath-based
> manipulation, or working with the DOM in jquery. there is a graph, but
> it's less important than the way you access it.
> 
> i see scenegraphs in OF's future, but i can't imagine them coming at the
> expense of immediate mode. i'd love to see a proposal for an elegant way
> of handling both. the closest thing to a precedent we have now is
> ofImage::setAnchor*()
> 
> 
> On Wed, Jul 1, 2015 at 1:20 PM, arturo castro <arturo at openframeworks.cc
> <mailto:arturo at openframeworks.cc>> wrote:
> 
>     btw, it also makes it so much easier to reason about from a user
>     perspective than trying to figure out global transformations. with
>     ofTranslate, rotate... you have to think like you are moving the whole
>     world to position things in it which is totally absurd. with an object
>     that is an ofNode you in terms of positioning, rotating and scaling that
>     object which it's way easier. it might be weird at first for people that
>     are used to global transformations but anyone that has used a 3d
>     software like cinema, 3d studio, blender... is used to think in that way
>     and beginners also get it way easier in my experience.
> 
>     On 01.07.2015 19:08, arturo castro wrote:
>     > for me, the best ideas right now in the graphics area are in three.js
>     > (haven't used unity though but i think it goes in the same direction),
>     > having a scene graph that allows to add objects that have their own
>     > transformations (our of3dPrimitive) instead of having global
>     > transformations makes way more sense and allows for a lot of
>     > optimizations internally that are really hard to get with anything
>     near
>     > immediate mode. i would slowly deprecate anything resembling immediate
>     > mode instead of trying to optimize it or give it a better syntax.
>     >
>     > On 01.07.2015 17:18, Theodore Watson wrote:
>     >> For me what I love about OF is how we have an abstracted
>     rendering system.
>     >> I think that its a big strength for OF in being able to shield
>     some of the complexity of OpenGL API changes from the user ( thus
>     making code more portable between systems and OF versions ).
>     >>
>     >> That said I would be curious to talk about ways we could make the
>     system more powerful.
>     >> The batch stuff in cinder looks like something that could be
>     abstracted and make me think something like this combined with a
>     scene graph where OF could auto optimize the submission of CPU ->
>     GPU data could be quite interesting to look at.
>     >>
>     >> One thing I would love for OF to do behind the scenes is
>     recognize that the next texture that is going to be bound is the
>     same as the current texture that is about to be unbound and then
>     skip the following two unbind / bind calls.
>     >>
>     >> I end up using diy scene graphs for all our projects and really
>     love classes having a draw() function which just gets called
>     automatically by the renderer.
>     >>
>     >> If we have abstracted calls anyway is there any reason we
>     couldn’t be essentially building a scene graph internally ( from
>     immediate calls ) and submitting all the GPU data in one go?
>     >>
>     >> Anyway really curious what people think.
>     >>
>     >> ----------------------------------------------
>     >> Theo Watson
>     >> http://theowatson.com
>     >> http://openframeworks.cc
>     >> ----------------------------------------------
>     >>
>     >> On Jun 30, 2015, at 6:31 AM, tim gfrerer
>     <tim at poniesandlight.co.uk <mailto:tim at poniesandlight.co.uk>> wrote:
>     >>
>     >>> We’ve had support for the latest OpenGL (that’s 4.5 if your
>     hardware/OS supports it) since 8.0, using the programmable renderer,
>     with work starting on it
>     (https://github.com/openframeworks/openFrameworks/pull/2097) over
>     two years ago.
>     >>>
>     >>> We might consider making the programmable renderer default
>     eventually, as its pretty mature by now.
>     >>>
>     >>> *
>     >>>
>     >>> GLM is a “de facto standard”, and i agree it would be great to
>     use it for our maths. I’d be all up for investing time in porting /
>     refactoring our maths stack if the consensus were to -when in doubt-
>     favour standardisation over backwards-compatibility.
>     >>>
>     >>> *
>     >>>
>     >>> That said,
>     >>>
>     >>> I like the focus of cinder’s approach, which i guess the
>     cinder-devs find easier to follow since they don’t support as many
>     platforms as openFrameworks does, and their user base seems to be
>     narrower, and maybe sailing closer to latest hardware/OS upgrades.
>     >>>
>     >>> Sometimes i feel like it’s almost as if cinder was more
>     following the Apple ("we have figured out a way that is right for
>     you") philosopy, with oF following a more linux approach ("we aim to
>     be approachable and run everywhere, and adopt new features quickly,
>     but there might be a couple of rough edges where you will have to
>     improvise and maybe contribute back”).
>     >>>
>     >>> I guess both approaches have their merits, and i would wish for
>     openFrameworks for an opportunity to get together (preferably
>     somewhere with bad WiFi) so that we could figure out a strategy and
>     on which areas to focus our efforts so that we don’t risk
>     over-extending.
>     >>>
>     >>> *
>     >>>
>     >>> For graphics, our top-level abstractions (like the shape / image
>     loading and drawing methods) are great, i think, since they allow
>     someone new to creative coding or oF to quickly draw things on the
>     screen, without having to worry about underlying renderers. Maybe we
>     should go even further:
>     >>>
>     >>> Underlying hardware APIs are fragmenting once again, and in 3 to
>     4 years we might have DirectX, Metal, Vulkan, and OpenGL (and maybe
>     something NVidia cooks up just to mess us all up even further)
>     competing as platforms, not to speak of their mobile derivatives.
>     >>>
>     >>> With our current platform OpenGL being phased out, having
>     mid-level abstractions like Textures, Buffers, Shaders and
>     Blit-targets agnostic of renderers, and even something of a basic
>     three.js - style scene-graph could be a move to make it easier to
>     adapt to new renderer APIs. But now i’m wildly speculating =)
>     >>>
>     >>> x
>     >>>
>     >>> Tim
>     >>>
>     >>>> On 30 Jun 2015, at 07:17, Pierre Proske <pierre at digitalstar.net
>     <mailto:pierre at digitalstar.net>> wrote:
>     >>>>
>     >>>> I'm pretty sure the OpenGL programmable renderer has 3.2
>     support, but in the examples there's a bit of mix and matching. I
>     think OF had 3.2 accessible before Cinder, but not 100% sure. I do
>     remember coding in Cinder last year and being frustrated by them
>     only supporting GLSL 1.2
>     >>>> However if Cinder are upgrading, they'll be doing it in a
>     uniform and across-the-board kind of way, whereas the current OF
>     OpenGL core profile varies depending on the renderer.
>     >>>>
>     >>>> On 30/06/15 11:09, Elliot Woods wrote:
>     >>>>> looks great
>     >>>>> especially the opengl move. and jealous of GLM.
>     >>>>>
>     >>>>> i'm generally confused about opengl in oF. I hope we make a
>     break for it one day too :)!
>     >>>>> what version are we on now?
>     >>>>>
>     >>>>> On Tue, Jun 30, 2015 at 5:46 AM Kyle McDonald
>     <kyle at kylemcdonald.net <mailto:kyle at kylemcdonald.net>> wrote:
>     >>>>> hi everyone,
>     >>>>>
>     >>>>> i just thought these were interesting posts, and wanted to share:
>     >>>>>
>     >>>>> https://forum.libcinder.org/#Topic/23286000002367073
>     >>>>> https://forum.libcinder.org/#Topic/23286000002367065
>     >>>>>
>     >>>>> historically, cinder has gone through a lot of the same
>     transitions as OF, sometimes at a faster pace, so it's interesting
>     to watch what is working for them and learn from it.
>     >>>>>
>     >>>>> the next version of cinder will be 0.9.0, and they're doing
>     some things that OF is also doing:
>     >>>>>
>     >>>>> - switching out libraries for native c++11 standard library.
>     (for OF, poco, for cinder, boost.)
>     >>>>> - moving to glm for math (this seems to be where OF is headed,
>     but not sure we'll do it the same way they have)
>     >>>>> - deprecating 32-bit on OSX
>     >>>>> - removing quicktime and qtkit on osx
>     >>>>> - adding AVFoundation, CoreMedia
>     >>>>> - vs 2015 support
>     >>>>>
>     >>>>> the way they're switching everything to GL3.2 is a bit more
>     advanced, and will happen with OF eventually but i don't think we
>     can do it the same way they have -- we need to maintain more
>     high-level abstraction and backwards compatibility.
>     >>>>>
>     >>>>> kyle
>     >>>>> _______________________________________________
>     >>>>> of-dev mailing list
>     >>>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     >>>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >>>>>
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>> of-dev mailing list
>     >>>>>
>     >>>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     >>>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >>>>
>     >>>>
>     >>>> --
>     >>>> web:
>     >>>> http://www.digitalstar.net
>     >>>>
>     >>>> twitter:
>     >>>> https://twitter.com/PierreProske
>     >>>> _______________________________________________
>     >>>> of-dev mailing list
>     >>>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     >>>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >>>
>     >>> _______________________________________________
>     >>> of-dev mailing list
>     >>> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     >>> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >>
>     >> _______________________________________________
>     >> of-dev mailing list
>     >> of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     >> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >>
>     > _______________________________________________
>     > of-dev mailing list
>     > of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     > http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
>     >
>     _______________________________________________
>     of-dev mailing list
>     of-dev at dev.openframeworks.cc <mailto:of-dev at dev.openframeworks.cc>
>     http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
> 
> 
> 
> 
> _______________________________________________
> of-dev mailing list
> of-dev at dev.openframeworks.cc
> http://dev.openframeworks.cc/listinfo.cgi/of-dev-openframeworks.cc
> 


More information about the of-dev mailing list