Hi All,
I have just checked in some further refinement to how the deprecated
functionality is handled. Rather than providing a #ifdef
OSG_USE_DEPRECATED_METHODS to switch on/off the compile of these
deprecated methods they have been moved entirely out of osg::Geometry,
and placed into a new
Hi All,
I have just finished a rather intensive bout of work on the new
cleaned up osg::Geometry, one of the most challenging parts was
providing a fallback for the deprecated array indices and
BIND_PER_PRIMITIVE usage. The new osg::Geometry doesn't support
rendering of geometries with indices
Hi Robert,
I tried out your code and it won't load a lot of geometry files even if they
are using fast path. The problem lies in that with the old Geometry::ArrayData
structure you could first set the binding and then the array. Now you are
forced to do this the other way around. The ive
Hi Pjotr,
On 18 June 2013 15:04, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
I tried out your code and it won't load a lot of geometry files even if they
are using fast path. The problem lies in that with the old
Geometry::ArrayData structure you could first set the binding and then the
Hi Pjotr,
Could you do an svn update, rebuild and then report how your models
load, hopefully the changes I've made will address the issue.
Cheers,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Hi Robert,
Great work! I just have a few questions/comments.
On 6/18/2013 7:42 AM, Robert Osfield wrote:
Hi All,
I have just finished a rather intensive bout of work on the new
cleaned up osg::Geometry, one of the most challenging parts was
providing a fallback for the deprecated array
Hi Robert,
Reading ive files works. Only reading .osg files that contain vertex attribute
arrays does not work yet. (both the binding and the normalization can be set
before the array itself right now).
Cheers,
Pjotr
robertosfield wrote:
Hi Pjotr,
Could you do an svn update, rebuild and
Hi Pjotr,
On 18 June 2013 15:37, Pjotr Svetachov pjotrsvetac...@gmail.com wrote:
Reading ive files works. Only reading .osg files that contain vertex
attribute arrays does not work yet. (both the binding and the normalization
can be set before the array itself right now).
Just applied a
Hi Judson,
On 18 June 2013 15:21, Judson Weissert jud...@mfrac.com wrote:
What is the difference between containsDeprecatedData() and
checkForDeprecatedData()? I see that containsDeprecatedData() just checks
the flag, what does the latter do? Forgive me if this is obvious, the names
suggest
Hi Robert,
On 6/18/2013 10:58 AM, Robert Osfield wrote:
Hi Judson,
On 18 June 2013 15:21, Judson Weissert jud...@mfrac.com wrote:
What is the difference between containsDeprecatedData() and
checkForDeprecatedData()? I see that containsDeprecatedData() just checks
the flag, what does the
Hi Judson,
On 18 June 2013 16:17, Judson Weissert jud...@mfrac.com wrote:
I looked at the implementations now (the Geometry.cpp changes were not
included in the online diff). Correct me if I am wrong, outside of the
optimizer, there is no code path that will call checkForDeprecatedData().
Hi Robert,
On 6/18/2013 11:47 AM, Robert Osfield wrote:
Hi Judson,
On 18 June 2013 16:17, Judson Weissert jud...@mfrac.com wrote:
I looked at the implementations now (the Geometry.cpp changes were not
included in the online diff). Correct me if I am wrong, outside of the
optimizer, there is
Hi.
I'm not sure I follow the discussion, since each post is starting to become
a separate article, but I'll try to tell what I think.
I don't know the policy on OSG ABI, but if it's to keep ABI compatible
between some releases, I would:
* add compile flag to select between old and new Geometry
HI Michael,
On 15 June 2013 15:59, michael kapelko korn...@gmail.com wrote:
I'm not sure I follow the discussion, since each post is starting to become
a separate article, but I'll try to tell what I think.
The thread might be a little meandering, but it's still roughly on
topic. The
Hi All,
My opinions about what to do in about osg::Geometry and the old
deprecated functionality is continuing to evolve. I'm starting to
feel that have an osg::GeometryDeprecated is going to be awkward to
maintain and for end users, while the new cleaned up osg::Geometry is
clearly much better
Hi Robert,
On Friday, June 14, 2013 13:08:43 Robert Osfield wrote:
My opinions about what to do in about osg::Geometry and the old
deprecated functionality is continuing to evolve. I'm starting to
feel that have an osg::GeometryDeprecated is going to be awkward to
maintain and for end
Hi Mattias et. al,
On 14 June 2013 14:23, Mathias Fröhlich mathias.froehl...@gmx.net wrote:
I really like the idea of GeometryDeprecated. It takes somehow more work to
make this happen for users. But at very first it's just about changing a
single
datatype. Once it compiles with
Hi All,
I have now got the old .osg, .ive loaders working with the new
osg::Geometry, and got the new serializers working. The way I've
tackled it was by storing the old deprecated IndexArray functionality
as UserData on the osg::Array that they were originally paired with.
This approach means
Hi All,
After brief foray back to do some client work and merging submissions
I have returned to looking at the new cleaned up Geometry and a
GeometryDeprecated fallback implementation. Currently I'm doing a
experimental build of the OSG with GeometryNew now named Geometry, and
the old Geometry
On 5 June 2013 06:45, Robert Osfield robert.osfi...@gmail.com wrote:
Right now I feel that sticking with the same naming convention that
users have been used will make for a smoother transition to the new
osg::Geometry. Ideally I want most users just to recompile their code
and not have any
While out this morning it occurred to me that the conundrum of how to
support the GeometryDeprecated from the existing .osg, .ive and
.osgt/.osgb/.osgx serializers might be to load the data as the new
streamlined osg::Geometry but place the extra data that osg::Geometry
no longer stores as
Hi All,
One of the changes I've discussed before, but as yet no made, is to
simplify osg::Geometry so that it drops the index arrays that you can
currently associated for vertex, normal, colour, texcoord arrays.
These index arrays aren't supported by OpenGL, instead have to be
emulated by
I have now started looking into what changes would be required to
osg::Geometry and have decided to make a copy of Geometry called
GoemetryNew and cut this down to see how easy it will be clean this
class up and what the knock on effects might be. Now I have dived in
and begun the process one
On 4 June 2013 09:42, Robert Osfield robert.osfi...@gmail.com wrote:
My current action plan is to get GeometryNew.cpp to build and run with
the osggeometry example
I have now got my quick clean up of Geometry as GeometryNew class with
osgeometry compiling and running correctly. My GeometryNew
Robert,
I think it's better to check it in.. Others would have the opportunity to
participate or evely siltently read the code and learn. Maybe there aer others
out there reading changes and try to learn as I do it usually ( If time
permits).
Regards,
Torben
--
Read this
On 4 June 2013 10:21, Torben Dannhauer tor...@dannhauer.info wrote:
I think it's better to check it in.. Others would have the opportunity to
participate or evely siltently read the code and learn. Maybe there aer
others out there reading changes and try to learn as I do it usually ( If
Hi Robert,
On Tuesday, June 04, 2013 09:42:10 Robert Osfield wrote:
Thoughts?
Great idea!
I see that the GeometryDeprecated is still needed.
... that means we will need this at least.
The begin/end emulation code could then probably move to wherever you move the
GeometryDeprecated class.
HI Mathias,
On 4 June 2013 13:53, Mathias Fröhlich mathias.froehl...@gmx.net wrote:
I see that the GeometryDeprecated is still needed.
... that means we will need this at least.
I don't think it'll be too difficult to maintain, and it'll be really
useful to old Geometry held in the existing
Hi,
On Tuesday, June 04, 2013 14:12:21 Robert Osfield wrote:
May be this is also an opportunity to throw out the deprecated dlists?
I don't reason a need to drop display lists in osg::Geometry, at least
at this point. Display lists are rather orthogonal to the rest of the
API.
One
Hi Robert,
Would you consider changing BIND_PER_PRIMITIVE code to do some kind of
internal conversion to fast path rendering, such as expanding the arrays
by 3x (duplicating the color or normal for each vertex) so that it can
use the per-vertex rendering path? I have certainly written code
Hi Peter,
On 4 June 2013 14:29, Peter Amstutz peter.amst...@tseboston.com wrote:
Would you consider changing BIND_PER_PRIMITIVE code to do some kind of
internal conversion to fast path rendering, such as expanding the arrays by
3x (duplicating the color or normal for each vertex) so that it
Hi Robert,
This is totally reasonable and on balance I agree with your reasoning.
I thought the feature deserved a little discussion before being sent
quietly into the night :-)
On 6/4/2013 9:44 AM, Robert Osfield wrote:
I believe that a fast path only osg::Geometry is worthy enough goal to
Hi Peter,
On 4 June 2013 15:34, Peter Amstutz peter.amst...@tseboston.com wrote:
This is totally reasonable and on balance I agree with your reasoning. I
thought the feature deserved a little discussion before being sent quietly
into the night :-)
;-)
The reason for me to raise this topic
Hi All,
I have now taken the next step and added the following methods to osg::Array:
/** Specify whether the array data should be normalized by OpenGL.*/
void setNormalize(bool normalize) { _normalize = normalize; }
/** Get whether the array data should be normalized
Hi,
Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile
devices. OpenGL_ES does not implement inmediate mode since its first
version, and display lists are no supported since OpenGL_ES 1.1. So it will
be good for those starting with ES and OpenSceneGraph.
Cheers.
On 4 June 2013 17:56, Jordi Torres jtorresfa...@gmail.com wrote:
Just a coment. Deprecate inmediate mode is also and advantage w.r.t. mobile
devices. OpenGL_ES does not implement inmediate mode since its first
version, and display lists are no supported since OpenGL_ES 1.1. So it will
be good
Hi Robert,
These changes sound good. I'm all for cleaning up the Geometry class.
You mentioned implementing some sort of backwards compatibility for the
serialization plugins. Does that mean existing osg files (osg, ive, osgb,
etc...) that use indices will automatically fall back to the
Hi Farshid,
On 4 June 2013 18:27, Farshid Lashkari fla...@gmail.com wrote:
You mentioned implementing some sort of backwards compatibility for the
serialization plugins. Does that mean existing osg files (osg, ive, osgb,
etc...) that use indices will automatically fall back to the
Hi All,
I have now completed the removal of ArrayData container and all slow
path support from GeometryNew. The size is now down to less than
2/3rd the size of the original Geometry.cpp. The largest bloat left
is with helper functions for verifying and correcting bindings, but I
now believe
robertosfield wrote:
The PreserveDataType and AttribDivisor are entirely
new and are intended to support new extensions being added to the OSG
- but their implementation will have to wait till the GeometryNew
refactor is further down the road.
This is great !
robertosfield wrote:
Hi Aurelien,
On 4 June 2013 21:33, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
robertosfield wrote:
The naming of Binding is something I'm note yet sure of, with the
introduction of AttribDivisor the binding becomes a bit less clearly
defined as well. Not sure what to make of this
41 matches
Mail list logo
