Thanks Pjotr, fix merged and submitted to svn/trunk.
On 27 June 2014 11:16, Pjotr Svetachov wrote:
> Hi Robert,
>
> I made a small change to DataOutputStream.cpp which makes saving Geodes
> possible again. This is only half a fix as it only will save a Drawable that
> is part of a Geode. But th
I was trying to save a file to .ive format today but that failed with the
message: "Unknown node in Group::write(), className()=Geometry"
So right now it looks like it's impossible to write to .ive files.
While osgt/osgb files work I looked at the code and noticed that the
osg::Drawable does not
Yes that seems to work. But I think that the warning is meant to inform that
you could get unexpected behavior if you don't watch out as explained here
(http://stackoverflow.com/questions/11965596/diamond-inheritance-scenario-compiles-fine-in-g-but-produces-warnings-errors)
(see last example of
HI Pjotr,
On 10 June 2014 10:43, Pjotr Svetachov wrote:
> The warning is still there.
Argghg
Could you try adding the run method directly to the problem callbacks i.e.
bool run(osg::Object* object, osg::Object* data) { return
NodeCallback::run(object,data); }
I could this at my end, b
The warning is still there.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59687#59687
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/list
HI Pjotr,
On 10 June 2014 09:01, Pjotr Svetachov wrote:
> It only fixed the warnings for set/getUserdata.
> The warning for the run method still exist. It might be that Microsoft chose
> to always output this warning.
I have just looked at the two example warnings related to inheritance
of the
It only fixed the warnings for set/getUserdata.
The warning for the run method still exist. It might be that Microsoft chose to
always output this warning.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59683#59683
_
Hi Pjotr,
I have checked in fixes to svn/trunk, could you try them out to see if
things are working cleanly now?
Thanks,
Robert.
On 6 June 2014 12:44, Pjotr Svetachov wrote:
> The warnings I get are:
>
> ClusterCullingCallback.h(12): warning C4250: 'osg::ClusterCullingCallback' :
> inherits 'o
The warnings I get are:
ClusterCullingCallback.h(12): warning C4250: 'osg::ClusterCullingCallback' :
inherits 'osg::NodeCallback::osg::NodeCallback::run' via dominance
(..\..\..\..\..\src\osgWrappers\serializers\osg\ClusterCullingCallback.cpp)
I:\Libraries\OpenSceneGraphTrunk\include\osg/Callbac
Hi Pjotr,
On 6 June 2014 09:21, Pjotr Svetachov wrote:
> I had to add OSG_EXPORT to osg::Callback and osg::StateSet::Callback to make
> it compile with visual studio 2013. I did get a lot of warnings about the run
> method being inherited via dominance from classes like
> ClusterCullingCallbac
I had to add OSG_EXPORT to osg::Callback and osg::StateSet::Callback to make it
compile with visual studio 2013. I did get a lot of warnings about the run
method being inherited via dominance from classes like ClusterCullingCallback.
But till now everything is working fine here.
Cheers,
Pjotr
Hi All,
I have now completed the bulk of my work on the new osg::Callback
class, this along with the more familiar callbacks like NodeCallback
can now be found in the include/osg/Callback header file. You can now
subclass directly from osg::Callback and attach to
Node/Drawable/StateSet/StateAttri
Hi Aurelien,
On 3 June 2014 20:28, Aurelien Albert wrote:
> Pjotr wrote:
>> Also whats the point of a Drawable::Update/Event/CullCallback now, should't
>> they be deprecated now that a Drawable is a Node and can use the Node's
>> callbacks?
>
>
> I think Pjotr is right there. Maybe there's a wa
Hi,
Pjotr wrote:
> Also whats the point of a Drawable::Update/Event/CullCallback now, should't
> they be deprecated now that a Drawable is a Node and can use the Node's
> callbacks?
I think Pjotr is right there. Maybe there's a way to solve this using C++ "type
erasure" : create an "osg::Abs
Hi Pjotr,
I have merged you callback test code into the existing osgcallback
example, added a new pathway that sets up the callbacks as per your
example. To access this pathway you run:
osgcallback --test
The output I'm currently getting is:
$ osgcallback --test | more
Numchildren with update
Hi Robert
Even if this change break the API, this seem the best choice to keep
OSG consistency
Cheers
David
2014-06-03 12:05 GMT+02:00 Robert Osfield :
> Hi All,
>
> I have returned to the task of refactoring of the core OSG to
> facilitate the promotion of Drawable to Node status. I have check
Hi All,
I have returned to the task of refactoring of the core OSG to
facilitate the promotion of Drawable to Node status. I have checked
in the following changes:
1) I have removed the temporary osg::Bound adapter class, while this
helped with porting there was a couple of cases where crashes w
License does not really matter. Same terms as the other examples is fine by me.
I don't mean to say to just depecrate the drawable callbacks without fixing
them. Of course we need to fix them, but we also need to deprecate them to make
clear to people that somewhere in the future those callbacks
HI Pjotr,
On 22 May 2014 08:17, Pjotr Svetachov wrote:
> Sure you can adapt and use it as an example.
Thanks. Is there any particular license you'd like it to be under?
Public domain/OSGPL/simple statement about it being OK to reuse like
in other examples?
> As you can't have a Drawable::Updat
Sure you can adapt and use it as an example.
As you can't have a Drawable::UpdateCallback on a osg::Node it sounds weird
that Node::setUpdateCallback(Object*) can accept a Drawable::UpdateCallback.
What do you do when someone passes a Drawable::UpdateCallback to a Node? I
rather have an compile
Hi Pjotr,
Thanks for the example. Would it be OK for me to use/adapt it as part
of the OpenSceneGraph/examples set so it could be used as a unit
tests?
I have been thinking about the overlap between Node and Drawable
Update/Event/CullCallbacks and one idea that currently appeals to me
is to have
I made a little testfile with all the permutations of nodes/drawables and
updatecallbacks could come up with. The last two would never come up in old
code and maybe only by accident in new code.
It adds 7 update callbacks.
For me only 4 are called and the parent group says that only 3 children r
HI Pjotr,
On 21 May 2014 09:14, Pjotr Svetachov wrote:
> Might moving the logic over to the add/remove parent methods and making
> special overloads for those methods in the drawable class be a solution? I
> don't know if it's better at the end but at least this would at least remove
> the nee
Might moving the logic over to the add/remove parent methods and making special
overloads for those methods in the drawable class be a solution? I don't know
if it's better at the end but at least this would at least remove the need to
have special handling of this in the setChild method (with a
Hi Pjotr,
On 20 May 2014 16:09, Pjotr Svetachov wrote:
> If you use the Drawable::setUpdateCallback method to add a
> osg::Drawable::UpdateCallback it will not fire because a group does not
> update it's NumChildrenRequiringUpdateTraversal variable when it has Drawable
> nodes that have callba
Hi Pjotr,
On 20 May 2014 13:22, Pjotr Svetachov wrote:
> I stumbled on a little bug with the new drawables. I was distributing points
> data into different drawables that I used in a LOD later. When simplifying
> the system to not use geodes anymore I came upon the following bug:
> If Drawable:
Hi Robert,
While trying to add an update callback to a geometry node that was attached to
a lod without using a geode I stumbled upon some bugs:
If you use the Drawable::setUpdateCallback method to add a
osg::Drawable::UpdateCallback it will not fire because a group does not update
it's NumChi
Hi Robert,
I stumbled on a little bug with the new drawables. I was distributing points
data into different drawables that I used in a LOD later. When simplifying the
system to not use geodes anymore I came upon the following bug:
If Drawable::getBoundingBox would compute an invalid bounding box
HI Sebastien,
On 15 May 2014 14:28, Sebastian Messerschmidt
wrote:
>> What exactly is the error you are seeing?
>
> Hi Robert, this is a linker error. I will rebuild clean and give you a
> detailed report if I can reproduce the issue.
I have just reviewed the src/osgUI/CMakeLists.txt and the sou
I fixed that linker error for myself but didn't commit anything yet as I though
that it was a work in progress. I had to change include/osgUI/Export and
src/osgUI/CMakeLists.txt to make it compile on my system (visual studio 2013).
See the attached files.
Cheers,
Pjotr
--
Read
Am 15.05.2014 15:25, schrieb Robert Osfield:
Hi Sebastian,
On 15 May 2014 12:55, Sebastian Messerschmidt
wrote:
Yes, But currently osg-trunk version is failing to link due to some missing
references to osgWidget in osgUI.
I'm not getting any build failure. I can't find any reference in the
o
Hi Sebastian,
On 15 May 2014 12:55, Sebastian Messerschmidt
wrote:
> Yes, But currently osg-trunk version is failing to link due to some missing
> references to osgWidget in osgUI.
I'm not getting any build failure. I can't find any reference in the
osgUI headers or sources relating to osgWidge
Am 15.05.2014 12:55, schrieb Robert Osfield:
HI Sebastian.
On 15 May 2014 11:24, Sebastian Messerschmidt
wrote:
As for the bound issue, I also would accept a break at the cost of
refactoring some lines of code instead of using some artificial construct
unifying the bounds at the cost of one in
Hi Pjotr,
On 15 May 2014 12:13, Pjotr Svetachov wrote:
> A side request, if you plan to keep the Bound struct can it be moved into
> it's own file? Right now osg/Plane has to include osg/Node for the Bound
> struct. Because osg/Plane is included by osg/Polytope which is included by
> osg/State
A side request, if you plan to keep the Bound struct can it be moved into it's
own file? Right now osg/Plane has to include osg/Node for the Bound struct.
Because osg/Plane is included by osg/Polytope which is included by osg/State
the recompile time increases a lot. In the osg project alone the
HI Sebastian.
On 15 May 2014 11:24, Sebastian Messerschmidt
wrote:
> As for the bound issue, I also would accept a break at the cost of
> refactoring some lines of code instead of using some artificial construct
> unifying the bounds at the cost of one indirection.
> OpenSceneGraph has grown very
Hi Robert,
I also welcome the decision, as it helps structuring scene graphs a lot
easier and removes some of the awkward handling of Geodes.
As for the bound issue, I also would accept a break at the cost of
refactoring some lines of code instead of using some artificial
construct unifying
Hi All,
On 15 May 2014 09:42, Robert Osfield wrote:
> I hadn't thought of this enlarged bounding volume issue with adding
> Drawable directly to Group. The solution would be to check whether a
> child is a Drawable and has a bounding box and then handle this in the
> Group::computeBound(). I ha
Our codebase consists of 350 files (50% are headers). There was only one place
where we were using the bounding boxes to draw a box around selected object to
highlight them as being selected. So when compiling without osg_use_bound we
had to change some getBound calls to getBoundingBox.
We of c
Hi Pjotr,
On 15 May 2014 09:08, Pjotr Svetachov wrote:
> I have compiled osg successfully with and without osg_use_bound and
> everything seems to work with our software. (For the record, I only had to
> change two lines of code to make our software compile without osg_use_bound)
Thanks for di
Hi David,
> Promoting osg::Drawable from being subclassed from osg::Object to
> osg::Node is really a good idea ?
> Why osg::Drawable is a subclass of osg::Object in original design ?
> Which concept are implemented by this design?
I think one should ask the question the other way around. What v
I have compiled osg successfully with and without osg_use_bound and everything
seems to work with our software. (For the record, I only had to change two
lines of code to make our software compile without osg_use_bound)
I must say that after thinking about this I share a bit of David concern. I
Hi All,
Promoting osg::Drawable from being subclassed from osg::Object to
osg::Node is really a good idea ?
Why osg::Drawable is a subclass of osg::Object in original design ?
Which concept are implemented by this design?
Except avoid the use of geode, what is the benefice of the new design ?
I
Hi All,
I have now checked in further improvements to the Drawable/Node Bound
changes. You can now compile and run the OSG with or without the new
Bound adapter class.
I am still undecided about the merits of the Bound class. My C++
developer instinct is not have the Bond class and push end use
HI Lionel,
On 14 May 2014 14:51, Lionel Lagarde wrote:
> In order to get the center of the bounding box of a drawable, using to Bound
> helper class, you have to do:
> const osg::BoundingBox &bbox = geometry->getBound(); // type cast operator
> osg::Vec3 c = bbox.center();
>
> Because:
> osg::Vec
Hi Pjotr,
Thanks for the testing. I think the problems you've seen are down to
me not completing the getBound() implementation in Drawable - the
Drawable::getBound() should return a Bound with both the
BoundingSphere and BoundingBox set. I have now done this
implementation and am about to check
In order to get the center of the bounding box of a drawable, using to
Bound helper class, you have to do:
const osg::BoundingBox &bbox = geometry->getBound(); // type cast operator
osg::Vec3 c = bbox.center();
Because:
osg::Vec3 c = geometry->getBound().center();
Will throw a segmentation faul
I tested the code in trunk with OSG_USE_BOUND defined and I now get crashes
when loading files. After some debugging it looks like expressions like these
(see Geode::computeBound() and Group::computeBound()):
bb.expandBy((*itr)->getBound());
do not work anymore because the compiler can not know
Hi Lionel,
On 14 May 2014 10:59, Lionel Lagarde wrote:
> The center() method exists in the BoundingBox interface. With the Bound
> interface you provide, this code would throw a seg fault:
> og::Vec3 c = geometry->getBound().center();
The Bound class that I have implemented so far only access th
The center() method exists in the BoundingBox interface. With the Bound
interface you provide, this code would throw a seg fault:
og::Vec3 c = geometry->getBound().center();
In order to avoid any modification of user code, the center method (and
all the methods defined in the BoundingBox and th
Hi Farshid,
On 13 May 2014 22:55, Farshid Lashkari wrote:
> Regarding the change to Node::ParentList, I think this will cause some
> breakage. I know I have a lot of code that assumes the elements of
> ParentList are group nodes and performs Group operations on them (addChild,
> removeChild, etc.
Hi Robert,
I'm definitely in favor of this change. It will simplify a lot of code.
Regarding the change to Node::ParentList, I think this will cause some
breakage. I know I have a lot of code that assumes the elements of
ParentList are group nodes and performs Group operations on them (addChild,
I have made a further tweak to my experimental Bound class, adding
center(), radius() from BoundingSphere and xMin(), yMin() etc. methods
from BoundingBox to help make it easier for Bound to act more like a
BoundingSphrere or BoundingBox.
In the code below I provide a segment that deliberately tri
HI Glenn,
On 13 May 2014 17:41, Glenn Waldron wrote:
> Robert, do you see this impacting the concept of data variance, which has
> traditionally had different semantics for a Drawable versus a Node?
No, the same rules will apply to Drawable in that their DataVariance
is used by the draw dispatch
Robert, do you see this impacting the concept of data variance, which has
traditionally had different semantics for a Drawable versus a Node?
Glenn Waldron / @glennwaldron
On Tue, May 13, 2014 at 11:13 AM, Robert Osfield
wrote:
> Hi All,
>
> Over the last day I have been experimenting with chan
I have come up with a possible solution to my Drawable::getBound()
conundrum, it's a bit hacky/convoluted and itself might introduce
problems... but here it is for discussion, code below.
The basic idea is to pass back a temporary Bound object from
getBound() and have this provide the type convers
HI Lionel,
On 13 May 2014 16:56, Lionel Lagarde wrote:
> Wonderful. Our code is full of:
> if the object is a drawable then
> do something for the drawable
> else
> do something for the node
This is one of the benefits. The existence of Geode and Drawable not
being a Node is actuall
Hi,
Wonderful. Our code is full of:
if the object is a drawable then
do something for the drawable
else
do something for the node
For the getBound problem, I think there is no solution. The return type
is not included in the function prototype.
Lionel.
On 13/05/2014 17:13, Robert
Hi All,
Over the last day I have been experimenting with changing
osg::Drawable so that it is subclassed from osg::Node rather than
osg::Object. The motivation behind this change is to make it simpler
to build scene graphs that only contain a single geometry and enabling
one to just directly atta
59 matches
Mail list logo
