Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I'm too deep in the shader work right now to pop up and take on another
topic, so will have to return to issues once this work is wrapped up -
should be in the next couple of days.

W.r.t serialization, work most of my testing I used .osgt and .osgb so for
a good range of uses it looks to be working fine but just ran a quick test
with your sign.osgt and it fails.  I can't dive into what might be wrong
right now so can't provide an specific suggestions as to what might be
amiss.

Does the .osg format work OK for this data? If so could you post a .osg
version so that it can be compared.

W.r.t serializer changes since 3.2.x, the main changes have been to make
the serializers more flexible so that it enables the better introspection
capabilities required by scripting support.  In theory this changes
shouldn't affect the reading/writing of .osgt and .osgb files, but perhaps
something has gone amiss here.  What it might be I can't say at all at this
stage.

Robert.




On 3 February 2015 at 09:53, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> Hi,
>
> I've just created some osgb/osgt files and most of them cannot be loaded
> anymore. They are failing with
> InputStream::readObject(): Unsupported wrapper class ☺
> for osgb files and
> AsciiInputIterator::readProperty(): Unmatched property Values, expecting
> UniqueID
> for osgt.
>
> I've attached the file in binary and text flavour which are not working
> for me.
> Can someone please check if they are behaving the same on their machines?
>
> @Robert: It seems something got broken with the serialization since the
> 3.2.x versions.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Hi Robert, can you have look into the issue?

I've attached two versions of the file.
The working one is created by simply using osgconv. The non-working 
version undergone some traversing by visitors, optimizers etc.

Version is the current trunk.
I'll try to chase on my own to pinpoint the problem.

Cheers
Sebastian


I'm too deep in the shader work right now to pop up and take on 
another topic, so will have to return to issues once this work is 
wrapped up - should be in the next couple of days.


W.r.t serialization, work most of my testing I used .osgt and .osgb so 
for a good range of uses it looks to be working fine but just ran a 
quick test with your sign.osgt and it fails.  I can't dive into what 
might be wrong right now so can't provide an specific suggestions as 
to what might be amiss.


Does the .osg format work OK for this data? If so could you post a 
.osg version so that it can be compared.


W.r.t serializer changes since 3.2.x, the main changes have been to 
make the serializers more flexible so that it enables the better 
introspection capabilities required by scripting support.  In theory 
this changes shouldn't affect the reading/writing of .osgt and .osgb 
files, but perhaps something has gone amiss here.  What it might be I 
can't say at all at this stage.


Robert.




On 3 February 2015 at 09:53, Sebastian Messerschmidt 
> wrote:


Hi,

I've just created some osgb/osgt files and most of them cannot be
loaded anymore. They are failing with
InputStream::readObject(): Unsupported wrapper class ☺
for osgb files and
AsciiInputIterator::readProperty(): Unmatched property Values,
expecting UniqueID
for osgt.

I've attached the file in binary and text flavour which are not
working for me.
Can someone please check if they are behaving the same on their
machines?

@Robert: It seems something got broken with the serialization
since the 3.2.x versions.

___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


#Ascii Scene 
#Version 116 
#Generator OpenSceneGraph 3.3.4 

osg::Group {
  UniqueID 1 
  Name "db" 
  UserDataContainer TRUE {
osg::DefaultUserDataContainer {
  UniqueID 2 
}
  }
  Children 1 {
osg::Group {
  UniqueID 3 
  Name "Entfernungsmesser_1000m" 
  Children 1 {
osgSim::MultiSwitch {
  UniqueID 4 
  Name "s_visible" 
  Children 1 {
osg::Group {
  UniqueID 5 
  Name "Entfernungsmarker_1000m" 
  Children 2 {
osg::Geode {
  UniqueID 6 
  Name "p1" 
  DataVariance STATIC 
  StateSet TRUE {
osg::StateSet {
  UniqueID 7 
  DataVariance STATIC 
  ModeList 2 {
GL_CULL_FACE ON 
GL_LIGHTING ON 
  }
  AttributeList 2 {
osg::Material {
  UniqueID 8 
  Ambient TRUE Front 0.427451 0.427451 0.427451 1 Back 
0.427451 0.427451 0.427451 1 
  Diffuse TRUE Front 0.427451 0.427451 0.427451 1 Back 
0.427451 0.427451 0.427451 1 
  Specular TRUE Front 0 0 0 1 Back 0 0 0 1 
  Emission TRUE Front 0 0 0 1 Back 0 0 0 1 
  Shininess TRUE Front 0 Back 0 
}
Value OFF 
osg::CullFace {
  UniqueID 9 
}
Value OFF 
  }
  TextureModeList 1 {
Data 1 {
  GL_TEXTURE_2D ON 
}
  }
  TextureAttributeList 1 {
Data 1 {
  osg::Texture2D {
UniqueID 10 
WRAP_S REPEAT 
WRAP_T REPEAT 
WRAP_R CLAMP 
MIN_FILTER LINEAR_MIPMAP_LINEAR 
MAG_FILTER LINEAR 
UnRefImageDataAfterApply TRUE 
Swizzle RGBA 
Image TRUE {
  ClassName osg::Image 
  UniqueID 11 
  FileName 
"G:\\Multimedia\\mm_svn\\SGeS

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I'm currently working on wrapping up the shader composition usage in
osgTerrain and not yet in place where I can down tools and take on another
potentially complicated subject.  Once I've wrapped up my current work I'll
have a look.  Others are welcome to dive in and have a look.

Robert.

On 18 February 2015 at 13:00, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

>  Hi Robert, can you have look into the issue?
>
> I've attached two versions of the file.
> The working one is created by simply using osgconv. The non-working
> version undergone some traversing by visitors, optimizers etc.
> Version is the current trunk.
> I'll try to chase on my own to pinpoint the problem.
>
> Cheers
> Sebastian
>
>
> I'm too deep in the shader work right now to pop up and take on
> another topic, so will have to return to issues once this work is wrapped
> up - should be in the next couple of days.
>
>  W.r.t serialization, work most of my testing I used .osgt and .osgb so
> for a good range of uses it looks to be working fine but just ran a quick
> test with your sign.osgt and it fails.  I can't dive into what might be
> wrong right now so can't provide an specific suggestions as to what might
> be amiss.
>
>  Does the .osg format work OK for this data? If so could you post a .osg
> version so that it can be compared.
>
>  W.r.t serializer changes since 3.2.x, the main changes have been to make
> the serializers more flexible so that it enables the better introspection
> capabilities required by scripting support.  In theory this changes
> shouldn't affect the reading/writing of .osgt and .osgb files, but perhaps
> something has gone amiss here.  What it might be I can't say at all at this
> stage.
>
>  Robert.
>
>
>
>
> On 3 February 2015 at 09:53, Sebastian Messerschmidt <
> sebastian.messerschm...@gmx.de> wrote:
>
>> Hi,
>>
>> I've just created some osgb/osgt files and most of them cannot be loaded
>> anymore. They are failing with
>> InputStream::readObject(): Unsupported wrapper class ☺
>> for osgb files and
>> AsciiInputIterator::readProperty(): Unmatched property Values, expecting
>> UniqueID
>> for osgt.
>>
>> I've attached the file in binary and text flavour which are not working
>> for me.
>> Can someone please check if they are behaving the same on their machines?
>>
>> @Robert: It seems something got broken with the serialization since the
>> 3.2.x versions.
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> ___
> osg-users mailing 
> listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Am 19.02.2015 um 16:55 schrieb Robert Osfield:

Hi Sebastian,

I'm currently working on wrapping up the shader composition usage in 
osgTerrain and not yet in place where I can down tools and take on 
another potentially complicated subject.  Once I've wrapped up my 
current work I'll have a look.  Others are welcome to dive in and have 
a look.

Okay,

Can someone else at least try to see if they get the same results/errors 
on their platforms. I'm using Visual Studio 2010 on Windows 7.
Right now the trunk version is unusable for me due to this bug, but I 
want/need the new shader composition.


Cheers
Sebastian



Robert.

On 18 February 2015 at 13:00, Sebastian Messerschmidt 
> wrote:


Hi Robert, can you have look into the issue?

I've attached two versions of the file.
The working one is created by simply using osgconv. The
non-working version undergone some traversing by visitors,
optimizers etc.
Version is the current trunk.
I'll try to chase on my own to pinpoint the problem.

Cheers
Sebastian



I'm too deep in the shader work right now to pop up and take on
another topic, so will have to return to issues once this work is
wrapped up - should be in the next couple of days.

W.r.t serialization, work most of my testing I used .osgt and
.osgb so for a good range of uses it looks to be working fine but
just ran a quick test with your sign.osgt and it fails.  I can't
dive into what might be wrong right now so can't provide an
specific suggestions as to what might be amiss.

Does the .osg format work OK for this data? If so could you post
a .osg version so that it can be compared.

W.r.t serializer changes since 3.2.x, the main changes have been
to make the serializers more flexible so that it enables the
better introspection capabilities required by scripting support. 
In theory this changes shouldn't affect the reading/writing of

.osgt and .osgb files, but perhaps something has gone amiss
here.  What it might be I can't say at all at this stage.

Robert.




On 3 February 2015 at 09:53, Sebastian Messerschmidt
mailto:sebastian.messerschm...@gmx.de>> wrote:

Hi,

I've just created some osgb/osgt files and most of them
cannot be loaded anymore. They are failing with
InputStream::readObject(): Unsupported wrapper class ☺
for osgb files and
AsciiInputIterator::readProperty(): Unmatched property
Values, expecting UniqueID
for osgt.

I've attached the file in binary and text flavour which are
not working for me.
Can someone please check if they are behaving the same on
their machines?

@Robert: It seems something got broken with the serialization
since the 3.2.x versions.

___
osg-users mailing list
osg-users@lists.openscenegraph.org


http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




___
osg-users mailing list
osg-users@lists.openscenegraph.org  

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I have just tried both files with svn/trunk version of the OSG.  I see both
have 3.3.4 version and latest SOVersion marked in them so you've made them
recently.

When I run the following I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class Drawables

All I get is blank window, and when I enable the stats by pressing 's' I
get odd resulting text suggesting an issue with what looks like a blending
issue.

When I run the second file I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer cow.osg
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer
e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer
e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer e_
e_fails.osgt  e_works.osgt
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer
e_fails.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class OVERRIDE|PROTECTED
AsciiInputIterator::readProperty(): Unmatched property }, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property Values, expecting
UniqueID
AsciiInputIterator::readProperty(): Unmatched property }, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
InputStream: Failed to read from stream. At osg::Group osg::Group
osg::Group osg::Group osg::Geode osg::Geometry
osgviewer: No data loaded

I haven't begun investigating yet.  Do you have an clues to what might be
amiss?  Do you have the original file in a form that I could load and have
it work on screen. For instance exporting via .ive and .osg?

Thanks,
Robert.



On 18 February 2015 at 13:00, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

>  Hi Robert, can you have look into the issue?
>
> I've attached two versions of the file.
> The working one is created by simply using osgconv. The non-working
> version undergone some traversing by visitors, optimizers etc.
> Version is the current trunk.
> I'll try to chase on my own to pinpoint the problem.
>
> Cheers
> Sebastian
>
>
> I'm too deep in the shader work right now to pop up and take on
> another topic, so will have to return to issues once this work is wrapped
> up - should be in the next couple of days.
>
>  W.r.t serialization, work most of my testing I used .osgt and .osgb so
> for a good range of uses it looks to be working fine but just ran a quick
> test with your sign.osgt and it fails.  I can't dive into what might be
> wrong right now so can't provide an specific suggestions as to what might
> be amiss.
>
>  Does the .osg format work OK for this data? If so could you post a .osg
> version so that it can be compared.
>
>  W.r.t serializer changes since 3.2.x, the main changes have been to make
> the serializers more flexible so that it enables the better introspection
> capabilities required by scripting support.  In theory this changes
> shouldn't affect the reading/writing of .osgt and .osgb files, but perhaps
> something has gone amiss here.  What it might be I can't say at all at this
> stage.
>
>  Robert.
>
>
>
>
> On 3 February 2015 at 09:53, Sebastian Messerschmidt <
> sebastian.messerschm...@gmx.de> wrote:
>
>> Hi,
>>
>> I've just created some osgb/osgt files and most of them cannot be loaded
>> anymore. They are failing with
>> InputStream::readObject(): Unsupported wrapper class ☺
>> for osgb files and
>> AsciiInputIterator::readProperty(): Unmatched property Values, expecting
>> UniqueID
>> for osgt.
>>
>> I've attached the file in binary and text flavour which are not working
>> for me.
>> Can someone please check if they are behaving the same on their machines?
>>
>> @Robert

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Hi Robert,

I tried to narrow it down by removing parts of the file. The first 
culprit seems to be in the TextureAttribute. Removing it, will move the 
error towards the end of the file.
I also counted the curly braces to see if the number of opening and 
closing tags matches, which is true.
Unfortunately the non-working files are produced by some bigger 
infrastructor (with a lot of visitors and an optimizer running over it) 
so it is hard to reproduce.

Hi Sebastian,

I have just tried both files with svn/trunk version of the OSG.  I see 
both have 3.3.4 version and latest SOVersion marked in them so you've 
made them recently.
Yes, the working version is built with osgconv, while the non-working 
processed a bit more. This should not affect serialization IMHO, it 
simply adds some more nodes.

Interestingly the error also occurs with the osgb format.


When I run the following I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables

All I get is blank window, and when I enable the stats by pressing 's' 
I get odd resulting text suggesting an issue with what looks like a 
blending issue.


When I run the second file I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer cow.osg
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_works.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_works.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer e_
e_fails.osgt  e_works.osgt
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_fails.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class OVERRIDE|PROTECTED
AsciiInputIterator::readProperty(): Unmatched property }, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property Values, 
expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property }, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
InputStream: Failed to read from stream. At osg::Group osg::Group 
osg::Group osg::Group osg::Geode osg::Geometry

osgviewer: No data loaded

I haven't begun investigating yet.  Do you have an clues to what might 
be amiss?  Do you have the original file in a form that I could load 
and have it work on screen. For instance exporting via .ive and .osg?

I will try to export to osg and ive if this helps.

Sorry, that I cannot give more insight since I'm not familiar with 
serialization approach. The only thing I can do is to narrow it down to 
the nodes which cause the problems.


Cheers
Sebastian



Thanks,
Robert.



On 18 February 2015 at 13:00, Sebastian Messerschmidt 
> wrote:


Hi Robert, can you have look into the issue?

I've attached two versions of the file.
The working one is created by simply using osgconv. The
non-working version undergone some traversing by visitors,
optimizers etc.
Version is the current trunk.
I'll try to chase on my own to pinpoint the problem.

Cheers
Sebastian



I'm too deep in the shader work right now to pop up and take on
another topic, so will have to return to issues once this work is
wrapped up - should be in the next couple of days.

W.r.t serialization, work most of my testing I used .osgt and
.osgb so for a good range of uses it looks to be working fine but
just ran a quick test with your sign.osgt and it fails.  I can't
dive into what might be wrong right now so can't provide an
specific suggestions as to what might be amiss.

Does the .osg format work OK for this data? If so could you post
a .osg version so t

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I've tried to get things rendering with the e_works.osgt and have found
that if I substitute in an image file that are part of the
OpenSceneGraph-Data/Images rather than the file references local to your
system I get it to load.  It looks like part of the problem relates to what
happens to the parser with it fails to load and image and then subsequent
parsing screws up.  It's very likely there are other problems lurking too.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Here's the osg-version (which is working)
It has taken the same path (visitors and optimizers) as the non-working 
osgt/osgb versions


Cheers
Sebastian



I tried to narrow it down by removing parts of the file. The first 
culprit seems to be in the TextureAttribute. Removing it, will move 
the error towards the end of the file.
I also counted the curly braces to see if the number of opening and 
closing tags matches, which is true.
Unfortunately the non-working files are produced by some bigger 
infrastructor (with a lot of visitors and an optimizer running over 
it) so it is hard to reproduce.

Hi Sebastian,

I have just tried both files with svn/trunk version of the OSG.  I 
see both have 3.3.4 version and latest SOVersion marked in them so 
you've made them recently.
Yes, the working version is built with osgconv, while the non-working 
processed a bit more. This should not affect serialization IMHO, it 
simply adds some more nodes.

Interestingly the error also occurs with the osgb format.


When I run the following I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables

All I get is blank window, and when I enable the stats by pressing 
's' I get odd resulting text suggesting an issue with what looks like 
a blending issue.


When I run the second file I get:

$ osgviewer e_works.osgt
AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer cow.osg
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_works.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_works.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class Drawables
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer e_
e_fails.osgt  e_works.osgt
robert@bracklin:~/Contributors/SebastianMesserschimdt$ osgviewer 
e_fails.osgt

AsciiInputIterator::readProperty(): Unmatched property }, expecting Value
AsciiInputIterator::readProperty(): Unmatched property {, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class OVERRIDE|PROTECTED
AsciiInputIterator::readProperty(): Unmatched property }, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property Values, 
expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property }, expecting 
UniqueID

InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting 
UniqueID
InputStream: Failed to read from stream. At osg::Group osg::Group 
osg::Group osg::Group osg::Geode osg::Geometry

osgviewer: No data loaded

I haven't begun investigating yet.  Do you have an clues to what 
might be amiss?  Do you have the original file in a form that I could 
load and have it work on screen. For instance exporting via .ive and 
.osg?

I will try to export to osg and ive if this helps.

Sorry, that I cannot give more insight since I'm not familiar with 
serialization approach. The only thing I can do is to narrow it down 
to the nodes which cause the problems.


Cheers
Sebastian



Thanks,
Robert.



On 18 February 2015 at 13:00, Sebastian Messerschmidt 
> wrote:


Hi Robert, can you have look into the issue?

I've attached two versions of the file.
The working one is created by simply using osgconv. The
non-working version undergone some traversing by visitors,
optimizers etc.
Version is the current trunk.
I'll try to chase on my own to pinpoint the problem.

Cheers
Sebastian



I'm too deep in the shader work right now to pop up and take on
another topic, so will have to return to issues once this work
is wrapped up - should be in the next couple of days.

W.r.t serialization, work most of my testing I used .osgt and
.osgb so for a good range of uses it looks to be working fine
but just ran a quick test with your sign.osgt and it fails.  I
can't dive into what might be wrong right now so can't provide
   

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Hi Robert,

Hi Sebastian,

I've tried to get things rendering with the e_works.osgt and have 
found that if I substitute in an image file that are part of the 
OpenSceneGraph-Data/Images rather than the file references local to 
your system I get it to load.  It looks like part of the problem 
relates to what happens to the parser with it fails to load and image 
and then subsequent parsing screws up.  It's very likely there are 
other problems lurking too.
I have the images sitting relative to the file. They get loaded 
correctly, so this doesn't make a difference here. Even removing the 
parts from the file using the image will still result in errors.




Robert.




___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

On 23 February 2015 at 12:44, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

> I have the images sitting relative to the file. They get loaded correctly,
> so this doesn't make a difference here. Even removing the parts from the
> file using the image will still result in errors.
>

OK, it looks like this file loading error that I'm getting is a separate
issue.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

With the .osg file I can load it reliably, and substituting in some local
images I get it to texture just fine.  However, as soon as I attempt to
converting this working .osg file to .osgt and then load the .osgt I get:

AsciiInputIterator::readProperty(): Unmatched property }, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property Values, expecting
UniqueID
AsciiInputIterator::readProperty(): Unmatched property }, expecting UniqueID
InputStream::readObject(): Unsupported wrapper class }
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
AsciiInputIterator::readProperty(): Unmatched property , expecting UniqueID
InputStream: Failed to read from stream. At osg::Group osg::Group
osg::Group osg::Group osg::Geode osg::Geometry

Unfortunately the warnings generated don't help pinpoint what part has gone
wrong.  Being able to recreate this issue from a working .osg file is
really useful.  Converting to .osgb and .osgx also results in problem files.

As yet I'm clueless to the cause of the problem.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I have been narrowing down the problems with the serialization and while I
haven't yet spotted the bug yet it does like the the serialization of the
VertexAttribArrayList is broken.  In your original files that list there as
being 8 arrays, but only two are listed.

If I change the number of arrays listed in the .osgt to via
"VertexAttribArrayList 2 {" then the file parses without error.  I don't
see anything on screen but it does at least load.

If I remove the VertexAttribArrayList entry completely then the file loads
and displays the sign just fine.

My next step will be to have a look at the serializers for
VertexAttribArrayList to see what might be going amiss.  If you've have any
spotted anything else useful let me know.

Robert
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

On 25 February 2015 at 09:22, Robert Osfield 
wrote:

>
> My next step will be to have a look at the serializers for
> VertexAttribArrayList to see what might be going amiss.  If you've have any
> spotted anything else useful let me know.
>
>
What looks to an issue is that refactor of the serializers to support use
of generic vector access of the  VertexAttribArrayList and TexCoordList
that I added to support scripting support fails to handle NULL entries in
these vectors, so if there are 8 entries in the VertexAttribArrayList, but
the first 6 are all NULL/empty then it'll just write out the arrays for the
final two valid ones.

To resolve this issue it looks like I'll need to separate out the
serialization of the VertexAttribArrayList and TexCoordList so that indices
are provide for each of the valid Arrays, or have the vector serialization
handle NULL entries.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Sebastian Messerschmidt]

Hi Robert,

Hi Sebastian,

I have been narrowing down the problems with the serialization and 
while I haven't yet spotted the bug yet it does like the the 
serialization of the VertexAttribArrayList is broken.  In your 
original files that list there as being 8 arrays, but only two are 
listed.


If I change the number of arrays listed in the .osgt to via 
"VertexAttribArrayList 2 {" then the file parses without error.  I 
don't see anything on screen but it does at least load.


If I remove the VertexAttribArrayList entry completely then the file 
loads and displays the sign just fine.


I think I've got it sorted out. The highest index I use for vertex 
attributes is 7, and I only use those two in the specific case.
So the "number" of array seems to be determined by the highest index 
only, assuming all indices in between are used.



geo->setVertexAttribArray(6, tsg->getTangentArray(), 
osg::Array::BIND_PER_VERTEX);
geo->setVertexAttribArray(7, tsg->getBinormalArray(), 
osg::Array::BIND_PER_VERTEX);


My next step will be to have a look at the serializers for 
VertexAttribArrayList to see what might be going amiss.  If you've 
have any spotted anything else useful let me know.
My best guess is the index thing. But this would also mean, that the 
array won't be bound to the correct index after loading, as I don't spot 
any binding in the serialized file.


In the "old" 3.3.1 (version 111) there is something like a canonical 
enumeration of the arrays:


VertexAttribData 8 {
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array FALSE
  Indices FALSE
  Binding BIND_OFF
  Normalize 0
}
Data {
  Array TRUE ArrayID 13 Vec4fArray 60 {
-1.59896e-006 1 1.64151e-006 1
-0.865942 0.500144 -4.98137e-006 1
-0.866024 0.53 -3.33793e-006 1



Robert


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebatian,

On 25 February 2015 at 09:52, Sebastian Messerschmidt <
sebastian.messerschm...@gmx.de> wrote:

>
>
> I think I've got it sorted out. The highest index I use for vertex
> attributes is 7, and I only use those two in the specific case.
> So the "number" of array seems to be determined by the highest index only,
> assuming all indices in between are used.
>
>
> geo->setVertexAttribArray(6, tsg->getTangentArray(),
> osg::Array::BIND_PER_VERTEX);
> geo->setVertexAttribArray(7, tsg->getBinormalArray(),
> osg::Array::BIND_PER_VERTEX);
>

I have now added a debug message to the  OutputStream::writeObject(const
osg::Object* obj ) and have confirmed that the serialization is attempting
to output a series of NULL objects which is just handles by ignoring them
completely so nothing is written out.

My current inclination is to come up with a special NULL_OBJECT type or
something similar to handle these cases.

The other approach is to have arrays populated via indices.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

The approach of writing out a "NULL" keyword when the serializer tries to
do a writeObject() on a NULL and handling of this in readObject() works
well for the .osgt and .osgx formats - both reading and writer, and with
this change I can no convert for your original .osg to .osgt or .osgx and
have everything load and display correctly.

However, for some reason this mechanism doesn't work properly under the
.osgb format.  I haven't worked out why yet, but in the ascii serializers
it only attempts twelve writeObject(NULL) but for the binary it tries to
over a hundred.

Back to having no clue why this is happening yet.  Will have to dig into
the binary serialization side.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.3.3/trunk won't load certain files

[Robert Osfield]

Hi Sebastian,

I have now tracked down the issue with the binary format not handling
NULL's, fix was a simple change, and with this I'm now able to generate and
re-read .osgt, .osgx and .osgb files generated from .osg files that contain
NULL entries in the Geometry::VertexAttribArrayList and TexCoordArrayList.

One problem with these changes is that they change the format in a non
backwards compatible way, and any .osgt, .osgx and .osgb files that have
been generated since the refactor of the vector serializer support will
need to be re-generated.  There isn't much I can do about this old files,
they are broken.

The fixes are now checked into svn/trunk.

Could you do an update and let me know if things work out fine.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org