openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] Re: openvrml-develop digest, Vol 1 #211 - 2 msgs

[Damian M. <da...@es...>]

After changing some header files which have addToScene in them for some
experimentation,

	vrml97node.h
	VrmlNode.h
	VrmlProto.h
	VrmlNodeScript.h

the re-make forgot to update VrmlScene.cpp which calls addToScene and
certainly includes VrmlNodeScript.h.

I had a look at the Makefile but couldn't figure out the fix quickly as it
was the last of my worries. So I just touched VrmlScene.cpp nd away I went.

Just thought it useful to know.

- Damian

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Rearchitecture issue

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

On Mon, 2002-04-29 at 05:01, ja...@on... wrote:
> En r=E9ponse =E0 Braden McDaniel <br...@en...>:
>=20
> >=20
> > The problem seems to be that there is no defined means of casting the
> > object while it's being constructed. I don't see how to get around
> > that.
> >=20
>=20
> It looks that even after having ensured that the NodeType member is creat=
ed, if
> ScriptNode is not fully constructed,  accessing its members or casting it=
s
> address (it is more or less like accessing its base class subobject) is s=
till an
> undefined operation.
>=20
> After analyzing the code posted to comp.lang.c++.moderated I guess that t=
he B
> class represents NodeType.
>=20
> In such a context another idea is to create a factory method or even an o=
bject
> that creates a B (NodeType) object on the heap then constructs a D object=
 that
> aggregates the B object.
>=20
> Something like:
>=20
>=20
> class B {};
>=20
> class A {
>   public:
>     A(B & b) {}
> };
>=20
> class C: public virtual A {
>   public:
>     C(B & b): A(b) {}
> };
>=20
>=20
> class D: public C {
>   public:
>   static D* create()
>   {
>     B* b =3D new B;
>     return new D(b);
>   }
>=20
>   D(B* b): A(*b), C(*b), m_b(b)
>   {}
>  =20
>   private:
>   std::auto_ptr<B> m_b;  =20
> };
>=20
> Now it should be C++ standard compliant but the ScriptNode objects cannot=
 be
> created on the stack with the create function. In such a case it is up to=
 class
> user code to provide a B object and construct a D object. Such an operati=
on may
> be simplified with a helper function creating a B object, but still its
> feasibility depends on how complicated is construction of a B object and =
if it
> can be separated from constructing a D object.

Cool... I think that would work.

At this point I've already committed a change that just avoids accessing
the NodeType from Node's constructor. I'm not sure how necessary that
access is. For one thing, as I mentioned, the flag that was being set
isn't ever getting checked. For another, I suspect it may be more
appropriate to make the method call in individual concrete Node subclass
constructors--a number of nodes will have a "nil" bounding volume
(interpolators, TimeSensor, etc.), and so shouldn't have a need to set
that flag at all. Or so I think.

> On the other hand I think that specifity of ScriptNode may justify such a=
n
> additional burden.

Yes; even under the current scheme, there are special construction rules
for ScriptNode.

> Maybe even addition of a 'create' inline static function to
> every Node derived class would appear useful? I guess most Node objects a=
re
> created dynamically (either by parser or user code) and such a function m=
ay
> handle some obvious constructor parameters ( like scene() ) and shield fr=
om any
> future object construction modifications.

Most nodes get constructed by a factory method on their associated
NodeType object. This doesn't work for ScriptNodes since their NodeTypes
are per-instance. As the code currently stands, ScriptNode is the only
node type that is constructed with an explicit call the the constructor
in client code.

Because it's already a special case, I don't have any problem using a
static factory method instead of a constructor call to create a new
Script node. And stack allocation is never going to be a realistic
scenario for Node instances anyway, so I don't see that as an issue
either.

However, I would like to get some justification of the need to access
the NodeType from Node's constructor before making special
accommodations so that can happen. It's quite comforting to know we have
a solution if we need it. Thanks!

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

Re: [openvrml-develop] Rearchitecture issue

[<ja...@on...>]

En réponse à Braden McDaniel <br...@en...>:

> 
> The problem seems to be that there is no defined means of casting the
> object while it's being constructed. I don't see how to get around
> that.
> 

It looks that even after having ensured that the NodeType member is created, if
ScriptNode is not fully constructed,  accessing its members or casting its
address (it is more or less like accessing its base class subobject) is still an
undefined operation.

After analyzing the code posted to comp.lang.c++.moderated I guess that the B
class represents NodeType.

In such a context another idea is to create a factory method or even an object
that creates a B (NodeType) object on the heap then constructs a D object that
aggregates the B object.

Something like:


class B {};

class A {
  public:
    A(B & b) {}
};

class C: public virtual A {
  public:
    C(B & b): A(b) {}
};


class D: public C {
  public:
  static D* create()
  {
    B* b = new B;
    return new D(b);
  }

  D(B* b): A(*b), C(*b), m_b(b)
  {}
  
  private:
  std::auto_ptr<B> m_b;   
};

Now it should be C++ standard compliant but the ScriptNode objects cannot be
created on the stack with the create function. In such a case it is up to class
user code to provide a B object and construct a D object. Such an operation may
be simplified with a helper function creating a B object, but still its
feasibility depends on how complicated is construction of a B object and if it
can be separated from constructing a D object. 

On the other hand I think that specifity of ScriptNode may justify such an
additional burden. Maybe even addition of a 'create' inline static function to
every Node derived class would appear useful? I guess most Node objects are
created dynamically (either by parser or user code) and such a function may
handle some obvious constructor parameters ( like scene() ) and shield from any
future object construction modifications.


Regards,
Janusz

Re: [openvrml-develop] Rearchitecture issue

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

On Sun, 2002-04-28 at 11:02, Janusz Szpilewski wrote:
> ----- Original Message -----
> From: Braden McDaniel
> To: ope...@li...
> Cc: ck...@us...
> Sent: Friday, April 26, 2002 11:31 PM
> Subject: [openvrml-develop] Rearchitecture issue
> 
> >Potential solutions
> >-------------------
> >There are three potential solutions I see:
> >       1. Without dramatically changing the design, figure out how to
> >         initialize the ScriptNode's NodeType before the Node
> >        constructor gets called.
> 
> Assuming that I understood well the problem...
> 
> According to the C++ standard the base classes are initialized in the order
> as specified in the class definition, hence a member can be forced to be
> initialized as the first by putting it into a separate base class that is
> specified as the first parent class.
> 
> Here comes a code snippet that shows this concept:
> 
> class NodeType {};
> class Node {};
> 
> class NodeTypeOwner
> {
> public:
>   NodeType m_nodeType;
> };
> 
> class ScriptNode : private NodeTypeOwner, public Node
> {};
> 
> Now NodeType is a member of the base class specified as the first and is
> always initialized before the Node subobject. Feasibility of such a solution
> depends on how complicated is initialization of  the NodeType member and if
> it depends on other members of the ScriptNode class.

Yup. That's pretty much what I tried. And those complications you
mention would appear to make it unfeasible. A posting I made to
comp.lang.c++.moderated has a simplified version of what I attempted.

http://groups.google.com/groups?dq=&hl=en&threadm=86vgaemq1f.fsf%40alex.gabi-soft.de&prev=/groups%3Fq%3Dcomp.lang.c%252B%252B.moderated%26meta%3Dsite%253Dgroups

> To deal with such problems the class NodeTypeOwner may have some utility
> methods  to create a NodeType object, or such an object may be created in
> two steps: at first be constructed enough to not crash by a base class
> subobject and its initalization may finally end in the ScriptNode
> constructor body.

The problem seems to be that there is no defined means of casting the
object while it's being constructed. I don't see how to get around that.

Braden

Re: [openvrml-develop] Rearchitecture issue

[Janusz S. <ja...@on...>]

----- Original Message -----
From: Braden McDaniel
To: ope...@li...
Cc: ck...@us...
Sent: Friday, April 26, 2002 11:31 PM
Subject: [openvrml-develop] Rearchitecture issue

>Potential solutions
>-------------------
>There are three potential solutions I see:
>       1. Without dramatically changing the design, figure out how to
>         initialize the ScriptNode's NodeType before the Node
>        constructor gets called.

Assuming that I understood well the problem...

According to the C++ standard the base classes are initialized in the order
as specified in the class definition, hence a member can be forced to be
initialized as the first by putting it into a separate base class that is
specified as the first parent class.

Here comes a code snippet that shows this concept:

class NodeType {};
class Node {};

class NodeTypeOwner
{
public:
  NodeType m_nodeType;
};

class ScriptNode : private NodeTypeOwner, public Node
{};

Now NodeType is a member of the base class specified as the first and is
always initialized before the Node subobject. Feasibility of such a solution
depends on how complicated is initialization of  the NodeType member and if
it depends on other members of the ScriptNode class.

To deal with such problems the class NodeTypeOwner may have some utility
methods  to create a NodeType object, or such an object may be created in
two steps: at first be constructed enough to not crash by a base class
subobject and its initalization may finally end in the ScriptNode
constructor body.

I hope this helps.
Regards,
Janusz

Re: [openvrml-develop] determining AudioClip node child of Sound node

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

On Fri, 2002-04-26 at 03:09, Michael Schuldt wrote:
> >How does the runtime know to render a visually rendered node? It knows
> >because the renderer walks the tree, and by design it won't visit a node
> >that shouldn't be rendered. Do we need something like an AudioRenderer?
> >That is, a class that works like the Viewer, only for audio instead of
> >geometry?
> 
> I think it would be a good part to use a AudioRenderer for SoundNodes.
> But the current architecture of openvrml hasn't a good class type 
> identification (only with toMovieTexture() or toGeometry() or something 
> like that);

I'm clear neither on what kind of RTTI you have in mind, nor how you are
envisioning its application.

> I don't know about the new  rearch branch, but I think it would be good 
> thing, if we use a class type identification like
> open inventor does.

Sorry... I'm not that familiar with Open Inventor. What does it do in
this regard?

> And then it would be easier to determine the Sound Nodes.
> Also it would be a good thing to use render actions which get the path to 
> the rendered objects. Then it is easier
> to determine transparency objects, render these at least and depth sorted.

I was thinking we'd have a Renderer class that would traverse the node
tree more or less like Viewer does now. The Renderer would contain both
an AudioRenderer and a GeometryRenderer, which could be accessed by
nodes' render method as needed.

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

[openvrml-develop] Rearchitecture issue

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

I've hit a bit of a wall on the rearchitecture branch, and I'm hoping to
get some opinions before deciding whether to climb over it or knock it
down.

Background
----------
Script nodes are unique in that interfaces get added to them at the
instantiation point. This has important implications for a type
information object for nodes. Whereas most nodes can share a single type
information object among all nodes of a given type, each Script node
instance must have its own type information object instance.

Problem
-------
I've gone to significant effort in the rearchitecture to make Script
nodes behave just like any other node type in all but a few
circumstances. ScriptNode inherits Node, which has a reference to the
NodeType object. While for most nodes the NodeType reference is
initialized with a pre-existing NodeType object, the NodeType for Script
nodes is part of the ScriptNode instance--so it doesn't get initialized
until the ScriptNode is initialized.

The implication of this is that when constructing a ScriptNode, while
ScriptNode's base class Node is being constructed, the reference to the
NodeType isn't valid yet.

This presents a problem for the call to setBVolumeDirty in Node's
constructor. setBVolumeDirty accesses the VrmlScene (through the invalid
NodeType), causing a segfault.

Potential solutions
-------------------
There are three potential solutions I see:
        1. Without dramatically changing the design, figure out how to
           initialize the ScriptNode's NodeType before the Node
           constructor gets called.
        2. Make a signficant design change.
        3. Make a rule, "Don't access the NodeType from the constructor
           for Node (or ChildNode)."

1 is the ideal solution. I'm not convinced it's possible, though. The
only possible contortion of the code I've been able to come up with
doesn't work in gcc 3.0.4, and is probably of questionable
well-formedness with respect to the C++ standard.

2 is least desirable for obvious reasons, but of course it's what needs
to happen if we can't come up with a viable alternative.

If 1 is indeed intractable, 3 starts to look very attractive. But is it
realistic? Node::setBVolumeDirty sets a flag on VrmlScene,
d_flags_need_updating. But as far as I can tell, this flag never gets
checked. cks, I think this is something you added. Can you tell me more
about it?

Braden

Re: [openvrml-develop] determining AudioClip node child of Sound node

[Reed H. <re...@ze...>]

> But the current architecture of openvrml hasn't a good class type 
> identification (only with toMovieTexture() or toGeometry() or something 
> like that);
> I don't know about the new  rearch branch, but I think it would be good 
> thing, if we use a class type identification like

What do you mean by class type identification? C++ has the special 
typeid() operator to determine the class of an object, as well as 
dynamic cast templates.
Why is runtime type ID necessary, though?

Re: [openvrml-develop] determining AudioClip node child of Sound node

[Michael S. <Mic...@gm...>]

>How does the runtime know to render a visually rendered node? It knows
>because the renderer walks the tree, and by design it won't visit a node
>that shouldn't be rendered. Do we need something like an AudioRenderer?
>That is, a class that works like the Viewer, only for audio instead of
>geometry?

I think it would be a good part to use a AudioRenderer for SoundNodes.
But the current architecture of openvrml hasn't a good class type 
identification (only with toMovieTexture() or toGeometry() or something 
like that);
I don't know about the new  rearch branch, but I think it would be good 
thing, if we use a class type identification like
open inventor does. And then it would be easier to determine the Sound Nodes.
Also it would be a good thing to use render actions which get the path to 
the rendered objects. Then it is easier
to determine transparency objects, render these at least and depth sorted.

Micha.

Re: [openvrml-develop] determining AudioClip node child of Sound node

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

On Thu, 2002-04-25 at 04:35, -oli- wrote:
> At 00:44 25.04.2002 -0400, you wrote:
> >On Sun, 2002-04-21 at 10:03, -oli- wrote:
> > > How can I find out from within the class NodeAudioClip if the AudioClip
> > > node is [currently] child (i.e. source) of a Sound node?
> >
> >You can't really do that.
> >
> > > I need this to determine if the audio data has to be played or not, 
> > because
> > > this check is done in the method NodeAudioClip::update().
> >
> >Perhaps this logic belongs in Sound rather than AudioClip.
> 
> But the determination if the clip is playing takes place in 
> NodeAudioClip::update(), _not_ in any method of the class NodeSound, what 
> makes sense, because the update()-method is called periodically from 
> VrmlScene::update() and the time dependance of the sound is in the 
> AudioClip-Node (not in the Sound-Node).

Hm... You're right.

> If I do it from NodeSound::render(), it would be only updated if the 
> scene/view changes, e.g. when the user navigates through the world.
> 
> >Remember, MovieTextures can be sound sources, too. As such, it seems like we'd
> >want to reuse the same logic regardless of what our sound source is.
> 
> IMHO this has to take place in NodeMovieTexture::update().

Yes. We might be able to share this logic in a method on SoundSourceNode
(in the rearch branch), but that really doesn't get us any closer to an
answer to your question.

How does the runtime know to render a visually rendered node? It knows
because the renderer walks the tree, and by design it won't visit a node
that shouldn't be rendered. Do we need something like an AudioRenderer?
That is, a class that works like the Viewer, only for audio instead of
geometry?

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

Re: [openvrml-develop] determining AudioClip node child of Sound node

[Reed H. <re...@ze...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


In general, are node links in openvrml one-way then (Parent -> child) ?


>> Remember, MovieTextures can be sound sources, too. As such, it seems 
>> like we'd
>> want to reuse the same logic regardless of what our sound source is.
>
> IMHO this has to take place in NodeMovieTexture::update().

Yeah, MovieTextures (or any other media-specific node) would know better 
how to play themselves.
Perhaps SoundNode::update() could be called by the world update(), and 
call all its children's update() methods??

(I don'tknow much about OVRML just making a guess)

reed

- --

Reed Hedges
re...@ze...
http://zerohour.net/~reed

Virtual Object System -- Internet Virtual Reality:
http://www.interreality.org

The owls are not what they seem.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjzIEYgACgkQxh9ID034ht0zzQCfWuQ5Wd9b1LjG34e/iP+LIxBC
cU4AnA7Ofymafbn/qrzYMCf/MxhZZi3Q
=MPkK
-----END PGP SIGNATURE-----

Re: [openvrml-develop] determining AudioClip node child of Sound node

[-oli- <ol...@fr...>]

At 00:44 25.04.2002 -0400, you wrote:
>On Sun, 2002-04-21 at 10:03, -oli- wrote:
> > How can I find out from within the class NodeAudioClip if the AudioClip
> > node is [currently] child (i.e. source) of a Sound node?
>
>You can't really do that.
>
> > I need this to determine if the audio data has to be played or not, 
> because
> > this check is done in the method NodeAudioClip::update().
>
>Perhaps this logic belongs in Sound rather than AudioClip.

But the determination if the clip is playing takes place in 
NodeAudioClip::update(), _not_ in any method of the class NodeSound, what 
makes sense, because the update()-method is called periodically from 
VrmlScene::update() and the time dependance of the sound is in the 
AudioClip-Node (not in the Sound-Node).
If I do it from NodeSound::render(), it would be only updated if the 
scene/view changes, e.g. when the user navigates through the world.

>Remember, MovieTextures can be sound sources, too. As such, it seems like we'd
>want to reuse the same logic regardless of what our sound source is.

IMHO this has to take place in NodeMovieTexture::update().

         -oli-
         (Oliver Baum)

Re: [openvrml-develop] determining AudioClip node child of Sound node

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

On Sun, 2002-04-21 at 10:03, -oli- wrote: 
> How can I find out from within the class NodeAudioClip if the AudioClip 
> node is [currently] child (i.e. source) of a Sound node?

You can't really do that.

> I need this to determine if the audio data has to be played or not, because 
> this check is done in the method NodeAudioClip::update().

Perhaps this logic belongs in Sound rather than AudioClip. Remember,
MovieTextures can be sound sources, too. As such, it seems like we'd
want to reuse the same logic regardless of what our sound source is.

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

[openvrml-develop] Different displays of the same scene

[Thomas <tho...@la...>]

Hello,

I would like to get two differents displays with two different points of 
view of the same VRML scene. I am using one scene with two different 
instances of my viewer (Viewer using the GtkGlArea). My problem is: I 
got a view only in the first display and the second one is black (even 
if I draw a red background before calling viewer->redraw()). Does 
anybody know how to fix this problem ?

Thank you very much,

Thomas.

[openvrml-develop] determining AudioClip node child of Sound node

[-oli- <ol...@fr...>]

Hi!

How can I find out from within the class NodeAudioClip if the AudioClip 
node is [currently] child (i.e. source) of a Sound node?
I need this to determine if the audio data has to be played or not, because 
this check is done in the method NodeAudioClip::update().

Thanks for help!

	-oli-

[openvrml-develop] request for the placement of openvrml header file into the win32 bin zip

[Gabor B. <gb...@cs...>]

Dear developers

I just downloaded only the openvrm win32 binary, I found it highly
surprising that this zip file contains the dll and the lib however it does
not contain the .h header files needed to actually use the lib.

I just thought I would note that.

Also it would be great to put some separate documentation in the
sourcforge tree. some somebody could just treat use the openvrml functions
without needing to go into the source to find out what the functions do.


Keep up the great work
Best wishes
Gabor

[openvrml-develop] MPG Reader

[Michael S. <Mic...@gm...>]

Hi,

how can I determine the frames per second for a mpgfile? Does the 
MpegStruct contain any information for this ?

Thx Micha.

Re: [openvrml-develop] openvrml on solaris 7 machine

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

On Fri, 2002-04-12 at 15:40, cal...@cs... wrote:
> 
> I recently built the newest openvrml on a solaris 7 box.
> I'm not sure how to test it, but lookat always
> dumps core when I run it -- a good indication that
> something is wrong.
> 
> I built Mesa-4.0.2 using pre-compiled glut binaries
> for solaris ... not the internal glut that Mesa provides.
> I couldn't get OpenVRML to build using those.
> 
> OpenVRML was built
> 
> ./configure  -with-glut-prefix=/usr/local/glut --with-x
> --prefix=/usr/local/openvrml  --with-MesaGL --with-MesaGLU
> --without-mozjs
> 
> 
> No compilation problems ... it just doesn't seem to work.
> 
> Any help would be appreciated!

Please file a bug. Use gdb to get a backtrace and include that in the
bug report.

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

[openvrml-develop] openvrml on solaris 7 machine

[<cal...@cs...>]

I recently built the newest openvrml on a solaris 7 box.
I'm not sure how to test it, but lookat always
dumps core when I run it -- a good indication that
something is wrong.

I built Mesa-4.0.2 using pre-compiled glut binaries
for solaris ... not the internal glut that Mesa provides.
I couldn't get OpenVRML to build using those.

OpenVRML was built

./configure  -with-glut-prefix=/usr/local/glut --with-x
--prefix=/usr/local/openvrml  --with-MesaGL --with-MesaGLU
--without-mozjs


No compilation problems ... it just doesn't seem to work.

Any help would be appreciated!

RE: [openvrml-develop] getting coordinates from ViewPoint- and Sound-Nodes

[Michael S. <Mic...@gm...>]

>
>That doesn't work. The result always is (0,0,0).
>:o(
>I inserted in NodeSound::render() this code:
>***snip***
>VrmlMatrix.MV = rc.getMatrix();
>SFVec3f o(0,0,0);
>SFVec3f pos;
>MV.multMatrixVec(o, pos);

first you may use MV.multVecMatrix(o,pos) and you may use the homogenous 
Coords,
try it again for my distance determination I do the same and i don't get 
0,0,0,0

I suppose, this proceeding will not include other transformations of 
parental Transform nodes that translation.

yes it does.

Micha.

RE: [openvrml-develop] getting coordinates from ViewPoint- and Sound-Nodes

[-oli- <ol...@fr...>]

At 13:42 12.04.2002 +0530, you wrote:
> > It worked - but using the inverse matrix:
> > After the modelview transform I used the following code:
> >
> > ***snip***
> > VrmlMatrix myMV = MV.affine_inverse();
> > SFVec3f globalVP(myMV[3][0], myMV[3][1], myMV[3][2]);
> > SFVec3f globalVUP(myMV[1][0], myMV[1][1], myMV[1][2]);
> > +++snap+++
> >
> > ...which stores the ViewPoint position w.r.t. the VRML-world coordinate
> > system in globalVP and the view-up vector in globalVUP (as I need it *g*).
> >
>
>"MV" ? Is it after viewpoint inverse matrix and navigation matrix ?

It's after the modelview transform ("if (vp) { [...] } else { [...] }  /* 
HERE */ " sth. about line 870).

> > What I still didn't figure out is my second issue:
> >
> > > > (2) How can I get the coordinates of a Sound node in the VRML-world
> > > > coordinate system?
>What about viewpoint's position and orientation as well as navigation
>information ? Because in the modelview matrix inside "rc", all these are
>included.

No other possibilities?
The matrix is always w.r.t. the OpenGL camera, isn't it?

> > How can I achieve this??
>
>Other routine "inverseTransform(VrmlMatrix..)" could help you. This will
>give inverse of the transformation stack above the node.

I need the viewpoint coordinates in the Sound::render() method then, which 
means to have a third class (call it AudioManager) which holds the ViewPoint

>Suggestion !!!!
>Why don't use const viewpoint as (0,0,0) and const view-up-vector as
>(0,1,0) and convert sound source's local coordinate to world coordinate
>using modelview matrix inside "rc"?

I also thought about that, but I need the global coordinates of both 
listener and sound sources for my further intentions.

Thanks!

         -oli-
         (Oliver Baum)

RE: [openvrml-develop] getting coordinates from ViewPoint- and Sound-Nodes

[S. K. B. <bo...@pa...>]

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of -oli-
> Sent: Thursday, April 11, 2002 11:25 PM
> To: ope...@li...
> Cc: S. K. Bose
> Subject: RE: [openvrml-develop] getting coordinates from ViewPoint- and
> Sound-Nodes
>
> It worked - but using the inverse matrix:
> After the modelview transform I used the following code:
>
> ***snip***
> VrmlMatrix myMV = MV.affine_inverse();
> SFVec3f globalVP(myMV[3][0], myMV[3][1], myMV[3][2]);
> SFVec3f globalVUP(myMV[1][0], myMV[1][1], myMV[1][2]);
> +++snap+++
>
> ...which stores the ViewPoint position w.r.t. the VRML-world coordinate
> system in globalVP and the view-up vector in globalVUP (as I need it *g*).
>

"MV" ? Is it after viewpoint inverse matrix and navigation matrix ?

>
> What I still didn't figure out is my second issue:
>
> > > (2) How can I get the coordinates of a Sound node in the VRML-world
> > > coordinate system?
>
> I.e. independed of the current ViewPoint and w.r.t. the VRML-world
> coordinate system.
> E.g. if the Sound node (field location = (0 2 0)) is a children of a
> Transform node (field translation = (1 0 0)), I need to get the actual
> coordinate of the Sound node, which is (1 2 0).

What about viewpoint's position and orientation as well as navigation
information ? Because in the modelview matrix inside "rc", all these are
included.

> How can I achieve this??

Other routine "inverseTransform(VrmlMatrix..)" could help you. This will
give inverse of the transformation stack above the node.

Suggestion !!!!
Why don't use const viewpoint as (0,0,0) and const view-up-vector as
(0,1,0) and convert sound source's local coordinate to world coordinate
using modelview matrix inside "rc"?

Thanks,

Bose

Thanks,

Bose

RE: [openvrml-develop] getting coordinates from ViewPoint- and Sound-Nodes

[-oli- <ol...@fr...>]

At 08:06 12.04.2002 +0200, you wrote:
>>> > (2) How can I get the coordinates of a Sound node in the VRML-world
>>> > coordinate system?
>
>You can get the MV and multiply it with (0,0,0)  then you have the vector 
>from the camera to Object,

That doesn't work. The result always is (0,0,0).
:o(
I inserted in NodeSound::render() this code:
***snip***
VrmlMatrix.MV = rc.getMatrix();
SFVec3f o(0,0,0);
SFVec3f pos;
MV.multMatrixVec(o, pos);
pos.print(cerr);
+++snap+++

>to get the Position, you may add the current position
>from Viewpoint in the VRML-world coordinate system, and now add the 
>location(field location) of Sound node.

I suppose, this proceeding will not include other transformations of 
parental Transform nodes that translation.
E.g. rotation has to be applied to the direction field of the Sound node.

Anyone any other ideas/hints?

Thanks!


         -oli-
         (Oliver Baum)

[openvrml-develop] Collision Detection

[Damian M. <da...@es...>]

We are trying to use OpenGL to do some crude Collision Detection.
This might be such a good idea but hear me out ...

The idea is that when we attempt to move in a direction, we want
to pick those polygons under the cursor position.  As long as we
collide with anything on this movement, we retain where the first
polygon where we will have an impact.  The next time we move, as
long as we haven't changed direction by changing the viewport or
moving off course, or probably a few other conditions, we don't
need to check for collision.

	GLint selectBuf[SOMELARGESIZE];

	glLoadName(name);	= { glPopName(); glPushName(name); }

	glSelectBuffer(BUFSIZE, selectBuf)
	glRenderMode(GL_SELECT);

	glMatrixMode(GL_PROJECTION);
	glPushMatrix();
	glLoadIdentity();

	glGetIntergerv(GL_VIEWPORT, viewport);

	// use a 5 by 5 box (say)
	pickX = pickY = 5;

	gluPickMatrix(cursorX, viewport[3]-cursorY, pickX, pickY, viewport);

	// Do we need to reset the perspective here

	glMatrixMode(GL_MODELVIEW);
	glInitNames();


	glMatrixMode(GL_PROJECTION);
	glPopMatrix();
	glMatrixMode(GL_MODELVIEW);
	glFlush();

	hits = glRenderMode(GL_RENDER);

	if (hits != 0)
	{
		// go through the selectBuf
		// and find polygon with nearest Z

		// Now this will return us the name of the hit objects
		// how do we go from the name of the hit object to
		// to the actual VRML structure so we can find out
		// its actual position is space


	}

Alternatively, what rudiments of Collision detection are available in the
existing code and has anybody got any notes/ideas on the directions we
should go to implement a first-attempt home-grown solution.

Thanks - Damian

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

RE: [openvrml-develop] hit_point and touchsensor

[S. K. B. <bo...@pa...>]

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of
> Michael Schuldt
> Sent: Thursday, April 11, 2002 10:09 PM
> To: ope...@li...
> Subject: [openvrml-develop] hit_point and touchsensor
> 
> 
> Hi,
> 
> could it be that the hit_point changed event doesn't worked on the 
> touchsensor ??

Possibly, It may be...

Thanks,

Bose