Hi All,
this is sent for Michael Raab, it bounced due to a large attachment. In the
interest of keeping everybody's Inbox unclogged the list rejects messages with
more than 200K of attachments. If you want to send us something bigger than
that, please upload it to a public file hoster like drop.io, rapidshare.com or
megaupload.com (or one of about 100 others). Thanks!
Hi Dirk, hi all
quick update on the issue:
1.) Taking off the graphOps removes the crash, thx for this info
2.) Unfortunatly, I cannot provide a LINE_STRIP example, but I can show you how
our importer generates them, see:
GeoPositions3fPtr pnts = GeoPositions3f::create();
GeoPTypesPtr type = GeoPTypesUI8::create();
GeoPLengthsPtr lens = GeoPLengthsUI32::create();
GeometryPtr geo = Geometry::create();
for (...)
{
beginEditCP(pnts);
pnts->addValue(Pnt3f(x,y,z));
endEditCP(pnts);
count++;
}
beginEditCP(type);
type->addValue(GL_LINE_STRIP);
endEditCP(type);
beginEditCP(lens);
lens->addValue(count);
endEditCP(lens);
beginEditCP(geo);
geo->setPositions(pnts);
geo->setTypes(type);
geo->setLengths(lens);
endEditCP(geo);
Does this look unusual?
3.) The same crash happens if I use osb files that contain textured materials.
I've attached an example. (Attachment is at
http://drop.io/OpenSG_Cluster_Problem, file package30.osb)
Hope this helps,
Michael
-------- Original-Nachricht --------
> > Datum: Mon, 12 Apr 2010 12:05:13 -0500
> > Von: Dirk Reiners <dirk.rein...@gmail.com>
> > An: opensg-users@lists.sourceforge.net
> > Betreff: Re: [Opensg-users] OpenSG 1.8 - Crash during sync
> >
> > Hi Michael,
> >
> > can you give us an update on this one? Did taking off the GraphOps make a
> > difference? If so, would you be able to provide us an example model with
> > LINE_STRIPs so we can figure out what's wrong?
> >
> > Thanks
> >
> > Dirk
> >
> >
> > On 04/07/2010 09:31 AM, Carsten Neumann wrote:
>> > >
>> > > hm, strange. I don't see a reason why GL_LINE_STRIP would make any part
> > of
>> > > the sync behave different than for any of the other primitive types. Are
>> > > these geometries "unusual" or different from the rest in your
> > application in
>> > > any other way? For example, do they use no index or a complicated
> > interleaved
>> > > index? Do they have a material that is distinct from the other
> > materials?
>> > > etc.
>> > >
>>> > >> We're using the OpenSG osb loader, don't know if this is a general
>>> > >> sync
>>> > >> problem or if the loader does something strange.
>> > >
>> > > Does it make a difference if you run the default graph ops or not? Using
>> > >
>> > > SceneFileHandler::the()->read("filename.osb", NULL);
>> > >
>> > > will prevent them from running (i.e. the second argument to read is a
>> > > GraphOpSeq*, a list of graph ops to apply to the loaded model).
> >
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Opensg-users mailing list
> > Opensg-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
