openvrml-develop

[openvrml-develop] Error loading vrml with 0.16.1, worked OK with 0.15.10

[Philip L. <ph...@ed...>]

Hi all,

I am loading a vrml file with OpenVRML (using sdl-viewer) that loads  
OK in 0.15.10, but on 0.16.1 bails out with this error:

openvrml/basetypes.cpp:2619: failed assertion `axis == axis.normalize()'

Is there any way to force openvrml to ignore these kinds of  
assertions???

It would also be good to have a means (at runtime) to suppress the  
warning:
warning: axis component of a rotation must be a normalized vector

since loading any VRML exported from Maya or 3DS Max generates  
zillions of these.

Phil.

Re: [openvrml-develop] Error loading vrml with 0.16.1, worked OK with 0.15.10

[Braden M. <br...@en...>]

On Thu, 2006-11-16 at 16:46 +1300, Philip Lamb wrote:
> Hi all,
> 
> I am loading a vrml file with OpenVRML (using sdl-viewer) that loads  
> OK in 0.15.10, but on 0.16.1 bails out with this error:
> 
> openvrml/basetypes.cpp:2619: failed assertion `axis == axis.normalize()'
> 
> Is there any way to force openvrml to ignore these kinds of  
> assertions???

It's a standard C assert; and the way to avoid these is to define NDEBUG
(i.e., add "-DNDEBUG" to CPPFLAGS when configuring).

But please send me the problem file. It's a bug that this assertion is
failing.

> It would also be good to have a means (at runtime) to suppress the  
> warning:
> warning: axis component of a rotation must be a normalized vector
> 
> since loading any VRML exported from Maya or 3DS Max generates  
> zillions of these.

Such files are not conforming. I am unlikely to add a mechanism to
OpenVRML to suppress them. However, openvrml::browser uses a
user-suppled std::ostream for its console output. You could supply an
ostream that filters these out.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] Non Conforming (Was RE: Error loading vrml with 0.16.1, worked OK with 0.15.10)

[John R. <ric...@sp...>]

Hello,

New thread since this is a "content" post, not a programming post.

Here is the problem.

MAYA and 3DS MAX are two of the market leaders and quite possibly make up a
majority of modeling and animation systems. So, those non conforming files
are gushing forth from the market leaders into the hard drives of lots of
artists.

I assume there are two ways to get VRML out of these systems.

Easy and Hard.

This assumption is based upon VRML export in Amapi 3D 6 and Carrara which
are mid level systems. I'll volunteer to add terrain to my SimVRML suite
from VUE 5 Infinite and LW9 just to test the process. It's just a WRL file
after all.

The easy way
The incredibly talented artist creates a masterpiece and clicks the Export
VRML menu item. At this point the VRML export crashes, succeeds with lots of
non comforming stuff that is useless or annoying to post process in VRML
authoring tools or miraculously pumps out beautiful VRML that OpenVRML and
the authoring tools love.

The Hard way
The incredibly talented artist creates a masterpiece after reading the
H-anim spec and the geoVRML spec and the VRML 97 spec and makes a virtual
world that is designed from scratch to be a VRML (or X3D) world that is
compliant and can be worked with in Flux studio or Axel Edge or BBedit to
make enough behaviors to satisfy their client. Then they click the VRML
export button. At this point the VRML export crashes, succeeds with lots of
non comforming stuff that is useless or annoying to post process in VRML
authoring tools or miraculously pumps out beautiful VRML that OpenVRML and
the authoring tools love.

The dominant theme is: "VRML viewers are at the mercy of the bean counters
at Autodesk (yes the AutoCAD people that own Maya and 3DS Max)" It is
irrelevant how capable the viewers are with respect to the core spec and the
extensions like h-anim, animation and terrain. If Autodesk does not beef up
it's export and work with Braden (and Keith Victor and the Blaxxun and
Octaga and ... programmers) then only the hard way followed by lots of post
production in Flux/BBedit (Axel is owned by a furniture manufacturer with
virtual showrooms and is dead). This comment applies to NewTek, DAZ, Maxon,
Avid (the video and audio people that now own Softimage), BLENDER.ORG,
Caligari, Poser People (I.E., Second Life avatars with proprietary morph
targets),...

Note: Poser did not have to mod their product, SL actually provided
developer tools to comform poser models to the SL API. Their bean counters
decided to do this since it is their business and Poser is the GODling of
avatar creators. Is Poser better than PG's toolset for avatars. It does not
matter, some commercial entity went and did it.

So, we are in a catch-22 situation here. Braden should NOT have to correct
VRML export from mainstream animation and modeling systems.

My original APPLEVILLE model should not have been a bloated, piggish,
sloppy, fat, lumbering, mother of all extraneous extra ASCII blank spaces
export from Carrara, but it was...even with some of the exotic export flags
selected. Of course, that was when Carrara would not crash on export.

Advice: I think that BLENDER.ORG is the key here. Blender is in the same
class as Maya, Max and LW (etc...) and they may update the exporter to
Braden's specifications. Maybe not, but....

Oh, and thanks Philip, even if the library remains at 155MB. It is the
thought that counts.

Oh, and when I do make APPLEVILLE, I'll add Braden Parkway in honor of you
know who.... Maybe Lamb & Lamb commercial district...

John F. Richardson

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf Of Braden
McDaniel
Sent: Wednesday, November 15, 2006 8:42 PM
To: ope...@li...
Subject: Re: [openvrml-develop] Error loading vrml with 0.16.1,worked OK
with 0.15.10

On Thu, 2006-11-16 at 16:46 +1300, Philip Lamb wrote:

<SNIP...>

> It would also be good to have a means (at runtime) to suppress the  
> warning:
> warning: axis component of a rotation must be a normalized vector
> 
> since loading any VRML exported from Maya or 3DS Max generates  
> zillions of these.

Such files are not conforming. I am unlikely to add a mechanism to
OpenVRML to suppress them. However, openvrml::browser uses a
user-suppled std::ostream for its console output. You could supply an
ostream that filters these out.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
openvrml-develop mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] Non Conforming

[Braden M. <br...@en...>]

On Thu, 2006-11-16 at 12:20 -0800, John Richardson wrote:

[snip]

> Advice: I think that BLENDER.ORG is the key here. Blender is in the same
> class as Maya, Max and LW (etc...) and they may update the exporter to
> Braden's specifications. Maybe not, but....

Ahem. They aren't *my* specifications. ;-) They're ISO's.

> Oh, and thanks Philip, even if the library remains at 155MB. It is the
> thought that counts.

After stripping, the binary tends to be about an order of magnitude
smaller than that for me (on x86_64 Linux).

> Oh, and when I do make APPLEVILLE, I'll add Braden Parkway in honor of you
> know who.... Maybe Lamb & Lamb commercial district...

:-)

Unfortunately not all vendors care equally about conformance. But if
noise generated by OpenVRML serves to generate bug reports to vendors
with conformance problems, then that noise serves a purpose.

As mentioned, this particular bit of noise can be filtered out in user
code. (Well, at least, that will be possible in 0.16.2. Sigh.) It does
require that someone care enough to go to the trouble; such is life.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] Error loading vrml with 0.16.1, worked OK with 0.15.10

[Braden M. <br...@en...>]

On Wed, 2006-11-15 at 23:41 -0500, Braden McDaniel wrote:
> On Thu, 2006-11-16 at 16:46 +1300, Philip Lamb wrote:

[snip]

> > It would also be good to have a means (at runtime) to suppress the  
> > warning:
> > warning: axis component of a rotation must be a normalized vector
> > 
> > since loading any VRML exported from Maya or 3DS Max generates  
> > zillions of these.
> 
> Such files are not conforming. I am unlikely to add a mechanism to
> OpenVRML to suppress them. However, openvrml::browser uses a
> user-suppled std::ostream for its console output. You could supply an
> ostream that filters these out.

Bah. Except right now, I'm using libantlr's default reporting mechanism
that goes to std::cerr rather than the std::ostream passed to browser.
That will be fixed: bug 1598088.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] Error loading vrml with 0.16.1, worked OK with 0.15.10

[Braden M. <br...@en...>]

On Thu, 2006-11-16 at 16:46 +1300, Philip Lamb wrote:
> Hi all,
> 
> I am loading a vrml file with OpenVRML (using sdl-viewer) that loads  
> OK in 0.15.10, but on 0.16.1 bails out with this error:
> 
> openvrml/basetypes.cpp:2619: failed assertion `axis == axis.normalize()'
> 
> Is there any way to force openvrml to ignore these kinds of  
> assertions???

This should be fixed now; both on MAIN and the OpenVRML-0_16-BRANCH. The
fix will appear in 0.16.2.

At the moment I'm in the final stages of getting 0.16.1 into Fedora
Extras. I feel like there are enough interesting fixes on the
OpenVRML-0_16-BRANCH to warrant 0.16.2; so the next item of business
will be making that release.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>