Hello Carsten,
thanks for your answers! I have more questions :-)
> [1] In hindsight I'd rather not have introduced TransitPtr, but it did
> seem like a good idea (to me) at the time :-/
> I have experimented a bit with a branch that mostly removes use of
> TransitPtr, but it is an application breaking change, so I'm not sure I
> want to pursue it.
> seem like a good idea (to me) at the time :-/
> I have experimented a bit with a branch that mostly removes use of
> TransitPtr, but it is an application breaking change, so I'm not sure I
> want to pursue it.
Maybe you can start a debate on the mailing list! I think most users will read here from time to time
and have an opinion on this..
1.)
We have the need to update some shader variables frequently, e.g. those who depend on our system time.
With 1.8 I checked each frame for newly created SHLChunks und there checked for certain uniform variable names using method hasUniformVariables().
Once found I updated the variables each frame..
How can this done in 2.0, may be there is a smarter way...
What I recently saw were OSGProceduralVariables. Can they be used for this purpose? Can all my shader programs share one variable, e.g. for current system time?
What happens if I write an OSGProceduralVariable to osb und reload it?
2.) Definitions: What is
- a stage?
- a partition?
- draw mode: SequentialPartitionDraw vs. ParallelPartitionDraw?
- a view area?
3.) commitchanges()
Could you please explain shortly what this exactly does? Is this relevant for multi-threaded/cluster applications only?
Thanks in advance,
Michael
Gesendet: Donnerstag, 30. Mai 2013 um 01:18 Uhr
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Von: "Carsten Neumann" <carsten_neum...@gmx.net>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] Porting 1.8 to 2.0
Hello Michael,
On 05/24/2013 04:28 AM, Michael Raab wrote:
> At a first look it works; I will test in details the next days. Thanks!
> I have more questions:
> 1.) RenderAction::setSmallFeatureCulling()/::setSmallFeaturePixels() -
> was this also removed?
yes.
> 2.) The compiler complains about converting TransitPointers to plain
> pointers, e.g. when a newly created object is given to a method:
> Example:
> viewport->setBackground(osg::DepthClearBackground::create()); // does
> not compile
> needs to be converted to:
> osg::DepthClearBackgroundPtr dcb = osg::DepthClearBackground::create();
> viewport->setBackground(dcb);
> We have much code that will need to be rewritten this way. Why can a
> RecPtr converted but a TransitPtr not?
one purpose of TransitPtr is/was to avoid code like this:
OSG::Viewport* vp = OSG::Viewport::create();
which produces a dangling pointer (the other is a micro-optimization to
avoid an increment, decrement on the ref count) [1]. Allowing TransitPtr
to implicitly convert to a raw pointer therefore defeats most of it's
purpose.
Cheers,
Carsten
[1] In hindsight I'd rather not have introduced TransitPtr, but it did
seem like a good idea (to me) at the time :-/
I have experimented a bit with a branch that mostly removes use of
TransitPtr, but it is an application breaking change, so I'm not sure I
want to pursue it.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
On 05/24/2013 04:28 AM, Michael Raab wrote:
> At a first look it works; I will test in details the next days. Thanks!
> I have more questions:
> 1.) RenderAction::setSmallFeatureCulling()/::setSmallFeaturePixels() -
> was this also removed?
yes.
> 2.) The compiler complains about converting TransitPointers to plain
> pointers, e.g. when a newly created object is given to a method:
> Example:
> viewport->setBackground(osg::DepthClearBackground::create()); // does
> not compile
> needs to be converted to:
> osg::DepthClearBackgroundPtr dcb = osg::DepthClearBackground::create();
> viewport->setBackground(dcb);
> We have much code that will need to be rewritten this way. Why can a
> RecPtr converted but a TransitPtr not?
one purpose of TransitPtr is/was to avoid code like this:
OSG::Viewport* vp = OSG::Viewport::create();
which produces a dangling pointer (the other is a micro-optimization to
avoid an increment, decrement on the ref count) [1]. Allowing TransitPtr
to implicitly convert to a raw pointer therefore defeats most of it's
purpose.
Cheers,
Carsten
[1] In hindsight I'd rather not have introduced TransitPtr, but it did
seem like a good idea (to me) at the time :-/
I have experimented a bit with a branch that mostly removes use of
TransitPtr, but it is an application breaking change, so I'm not sure I
want to pursue it.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
