openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] Problems with normal vectors beeing not normalized

[<MSo...@ya...>]

Hi Braden,

> I've just checked in a change to normalize the vec3f returned by
> indexFaceNormal. Does this fix the problem? 

Thanks! This should fix it. I will give it a try over the weekend.

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.2/251 - Release Date:
04.02.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problems with normal vectors beeing not normalized

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

On Sat, 2006-02-04 at 11:49 +0100, Michael Sögtrop wrote:

> > > The normals are not smoothed (the face is rendered with 
> > flat color as 
> > > it should be) but the normal vector is not normalized.

Okay. I think I finally found it. :-)

insertShellConvex calls indexFaceNormal, which is where the normal
generation happens.

I've just checked in a change to normalize the vec3f returned by
indexFaceNormal. Does this fix the problem?

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

[openvrml-develop] Re: Problems with normal vectors beeing not normalized

[<MSo...@ya...>]

Hi Braden,

> > The normals are not smoothed (the face is rendered with 
> flat color as 
> > it should be) but the normal vector is not normalized.
> 
> "Not normalized"? I don't know what you mean by that. "Not
normalized"
> generally means that the components haven't been adjusted to 
> be proportional to 1. But the case here is that OpenVRML 
> isn't supplying OpenGL with normals because it hasn't generated
them.

OpenVRML creates the right normal vectors in this case. The only
problem with these normal vectors is, that their length is not 1, as
it should be for a normal vector. Most shaders go wild if you supply
unnormalized normal vectors. If I tell OpenGL to normalize all normal
vectors (that is to keep their directions but to devide them by their
length) the model looks perfect. But normalizing all normal vectors is
a time consuming operations, because it requires calculating a square
root and a division for every normal vector. Since 99.99% of all
normal vectors already have a length of 1, this would be quite a waste
of computation time.

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.1/250 - Release Date:
03.02.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] huge model

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

On Fri, 2006-02-03 at 15:46 +0100, vr...@he... wrote:
> are there any limitations on the size of an vrml file in OpenVRML?

Nothing concrete. However, I wouldn't be surprised if there are bugs
with very large models.

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

[openvrml-develop] huge model

[<vr...@he...>]

Hi all,

are there any limitations on the size of an vrml file in OpenVRML? I have a file
with one indexed face set node and viewpoint. In total there a some million
triangles and the file size is about 80MB. I tested it in other viewers and it
works. In OpenVRML it loads too, without any error, the viewpoint is set right
and i got also a bounding sphere (i saw it with the debug mode) but there is
nothing inside or isn't shown. Any suggestions?

Thanks & Best wishes
joerg

Re: [openvrml-develop] Re: Problems with normal vectors beeing not normalized

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

On Wed, 2006-02-01 at 21:31 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > >  Are such per
> > > face normal vectors calculated somewhere?
> > 
> > No. Nor is it obvious to me that they should be. I don't 
> > understand why per-vertex normal generation wouldn't satisfy 
> > your requirement. (But then, perhaps I don't understand the 
> > visual effect you're looking for.) 
> G
> My problem is that the complete modell looks pefect, except very
> simple flat faces (e.g. a ball looks ok, but a simple flat cube looks
> wrong). Because the faces are flat, there are no normals given for the
> vertices of these faces in the VRML file, because they are redundant
> for flat faces.

They're only redundant if the runtime can be relied upon to generate
desirable ones. I do not mean to excuse OpenVRML's failure to make any
attempt to generate normals--clearly it should; however, not specifying
them in the model *is* deferring to the particulars of an
implementation.

>  It should be this case:
> 
> > If the normal field is NULL, the
> > browser shall automatically generate normals, using creaseAngle
> > to determine if and how normals are smoothed across shared
> > vertices (see 4.6.3.5, Crease angle field).

Right. The spec doesn't say whether the generated normals should be
per-vertex or per-face. The comment in OpenVRML assumes that they would
be generated per-vertex.

I'm no expert on normal generation; but it's my impression that, in
general, per-vertex normals are preferred as they yield better shading.

> The normals are not smoothed (the face is rendered with flat color as
> it should be) but the normal vector is not normalized.

"Not normalized"? I don't know what you mean by that. "Not normalized"
generally means that the components haven't been adjusted to be
proportional to 1. But the case here is that OpenVRML isn't supplying
OpenGL with normals because it hasn't generated them.

> Shall I just send a screenshot?

It would be better to file a bug on SourceForge and attach a screenshot
there. Note that there is already a task related to this:

        <http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=24101&group_id=7151&group_project_id=2579>

But you can't attach files to tasks; so we can have a bug, too.

What I'm trying to get from you, though, is an explanation of why
implementing per-vertex normal generation wouldn't solve your problem. I
think it would. You seem to be asking for different code paths for
normal generation depending on the value of normalPerVertex. The VRML97
spec doesn't appear to require that. Nonetheless, if there's a
compelling case for it, it could be added.

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

[openvrml-develop] Re: Problems with normal vectors beeing not normalized

[<MSo...@ya...>]

Hi Braden,

> >  Are such per
> > face normal vectors calculated somewhere?
> 
> No. Nor is it obvious to me that they should be. I don't 
> understand why per-vertex normal generation wouldn't satisfy 
> your requirement. (But then, perhaps I don't understand the 
> visual effect you're looking for.) 

My problem is that the complete modell looks pefect, except very
simple flat faces (e.g. a ball looks ok, but a simple flat cube looks
wrong). Because the faces are flat, there are no normals given for the
vertices of these faces in the VRML file, because they are redundant
for flat faces. It should be this case:

> If the normal field is NULL, the
> browser shall automatically generate normals, using creaseAngle
> to determine if and how normals are smoothed across shared
> vertices (see 4.6.3.5, Crease angle field).

The normals are not smoothed (the face is rendered with flat color as
it should be) but the normal vector is not normalized. Shall I just
send a screenshot?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.0/248 - Release Date:
01.02.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problems with normal vectors beeing not

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

On Mon, 2006-01-30 at 22:17 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > > Can you point me to the code where the normals for such things are
> 
> > > calculated?
> > 
> > I think the problem is that they aren't.
> > 
> > openvrml::gl::viewer::insert_shell has a comment in it noting 
> > that per-vertex normal generation is not implemented. 
> 
> I am not an VRML expert, but I would say that these are faces that
> have one face normal, rather than per-vertex normals. In other viewers
> these faces are rendered as flat faces with all the same color so all
> vertices of these faces must have the some normal vector.

Are you talking about adjacent polygons that lie fully in the same
plane?

>  Are such per
> face normal vectors calculated somewhere?

No. Nor is it obvious to me that they should be. I don't understand why
per-vertex normal generation wouldn't satisfy your requirement. (But
then, perhaps I don't understand the visual effect you're looking for.)

This is what the VRML97 spec has to say on the issue (6.23):

        If the normal field is not NULL, it shall contain a Normal node
        whose normals are applied to the vertices or faces of the
        IndexedFaceSet in a manner exactly equivalent to that described
        above for applying colours to vertices/faces (where
        normalPerVertex corresponds to colorPerVertex and normalIndex
        corresponds to colorIndex). If the normal field is NULL, the
        browser shall automatically generate normals, using creaseAngle
        to determine if and how normals are smoothed across shared
        vertices (see 4.6.3.5, Crease angle field).

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

[openvrml-develop] Re: Problems with normal vectors beeing not

[<MSo...@ya...>]

Hi Braden,

> > Can you point me to the code where the normals for such things are

> > calculated?
> 
> I think the problem is that they aren't.
> 
> openvrml::gl::viewer::insert_shell has a comment in it noting 
> that per-vertex normal generation is not implemented. 

I am not an VRML expert, but I would say that these are faces that
have one face normal, rather than per-vertex normals. In other viewers
these faces are rendered as flat faces with all the same color so all
vertices of these faces must have the some normal vector. Are such per
face normal vectors calculated somewhere?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
27.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problems with normal vectors beeing not normalized

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

On Sat, 2006-01-28 at 15:57 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> I just found that all faces that are completely flat and do not have a
> normal vector given with them (at least those with more than 3
> corners) seem to be affected by this problem. E.g.:

[snip]

> Can you point me to the code where the normals for such things are
> calculated?

I think the problem is that they aren't.

openvrml::gl::viewer::insert_shell has a comment in it noting that
per-vertex normal generation is not implemented.

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

Re: [openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Sat, 2006-01-28 at 14:45 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > BUT... if you're doing the work and you want to implement 
> > this, it's your call. For a patch to OpenVRML, though, I 
> > would like to see this data structure remain consistent with 
> > the Pair Associative Container concept[*], even if it doesn't 
> > fully model it.
> 
> Ok, I am looking into this. I just wonder if an Associative Container
> would be good enough?

Perhaps; the Pair Associative Container just gives you a place to store
the key when the key_type and the value_type are not the same. I am
under the impression that, in this case, they would be different.

> Also is there something to handle groups of IDs in STL?

Possibly; precisely what do you mean by "handle"?

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

[openvrml-develop] UNSBUSCRIBE

[Nuli I. <nu...@ev...>]

UNSUBSCRIBE

Michael Sögtrop wrote:

>Hi Braden,
>
>I just found that all faces that are completely flat and do not have a
>normal vector given with them (at least those with more than 3
>corners) seem to be affected by this problem. E.g.:
>
>geometry IndexedFaceSet {
>solid FALSE
>coord Coordinate {
>	point	[
>		 240 1202.43 935,
>		 240 1200 935,
>		 240 1129.8 924.729,
>		 240 1065.49 894.776,
>		 240 139.996 286.866,
>		 240 73.0611 255.691,
>		 240 0 245,
>		 240 -56.4157 245,
>		 240 15.1684 273.006,
>		 240 124.899 309.851,
>		 240 1050.4 917.761,
>		 240 1121.92 951.076,
>		 240 1200 962.5,
>		 240 1202.43 962.5,
>		]
>	}
>coordIndex [
> 5,9,6,-1,
> 9,8,6,-1,
> 6,8,7,-1,
> 0,13,1,-1,
> 13,12,1,-1,
> 1,12,2,-1,
> 12,11,2,-1,
> 2,11,3,-1,
> 11,10,3,-1,
> 3,10,4,-1,
> 10,9,4,-1,
> 4,9,5,-1,
>]
>
>Can you point me to the code where the normals for such things are
>calculated?
>
>Best regards,
>
>Michael
>
>  
>

[openvrml-develop] Re: Problems with normal vectors beeing not normalized

[<MSo...@ya...>]

Hi Braden,

I just found that all faces that are completely flat and do not have a
normal vector given with them (at least those with more than 3
corners) seem to be affected by this problem. E.g.:

geometry IndexedFaceSet {
solid FALSE
coord Coordinate {
	point	[
		 240 1202.43 935,
		 240 1200 935,
		 240 1129.8 924.729,
		 240 1065.49 894.776,
		 240 139.996 286.866,
		 240 73.0611 255.691,
		 240 0 245,
		 240 -56.4157 245,
		 240 15.1684 273.006,
		 240 124.899 309.851,
		 240 1050.4 917.761,
		 240 1121.92 951.076,
		 240 1200 962.5,
		 240 1202.43 962.5,
		]
	}
coordIndex [
 5,9,6,-1,
 9,8,6,-1,
 6,8,7,-1,
 0,13,1,-1,
 13,12,1,-1,
 1,12,2,-1,
 12,11,2,-1,
 2,11,3,-1,
 11,10,3,-1,
 3,10,4,-1,
 10,9,4,-1,
 4,9,5,-1,
]

Can you point me to the code where the normals for such things are
calculated?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
27.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[openvrml-develop] Problems with normal vectors beeing not normalized

[<MSo...@ya...>]

Hi Braden,

I found that some faces of one of my VRML models look odd (wrong
brightness) unless GL_NORMALIZE is enabled. The model looks right with
other VRML viewers. I just wanted to ask if there are some known
issues with normal vectors beeing not normalized or if I should
research the exact cause or if I should always use
glEnable(GL_NORMALIZE).

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
27.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

[openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[<MSo...@ya...>]

Hi Braden,

> BUT... if you're doing the work and you want to implement 
> this, it's your call. For a patch to OpenVRML, though, I 
> would like to see this data structure remain consistent with 
> the Pair Associative Container concept[*], even if it doesn't 
> fully model it.

Ok, I am looking into this. I just wonder if an Associative Container
would be good enough?

Also is there something to handle groups of IDs in STL?

Best regards,

Michael


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
27.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Thu, 2006-01-26 at 23:18 +0100, Michael Sögtrop wrote:
> Hi Braden
> 
> > I think I do not understand how your "view arrays" work. They are an
> > array of viewer::object_id? How are they indexed?
> > 
> > Don't you need an associative array (of whatever implementation) in
> > either case? It seems to me you either map node* to 
> > viewer::object_id in
> > the viewer, or you map viewer* to viewer::object_id in the node.
> 
> Those nodes in a scene that are creating references in the view get a
> unique ID that is counted up from 1. The IDs can be managed by the
> scene or browser and IDs should be recycled if a node is deleted, so
> that the IDs are usually dense and can be used as direct array index.
> What the array contains depends on the view, I would say. A GL view
> might store GL list indices. A different view might store something
> else. How do you like this concept?

I see; so it's a specialized kind of associative array.

Clever; but it strikes me as a premature optimization. My inclination
would be to use an off-the-shelf component (i.e., std::map), and later
replace it if it proves inadequate. I appreciate the memory analysis
you've offered; but as far as I'm concerned there are bigger fish to
fry; so I favor the solution that involves Less Code.

BUT... if you're doing the work and you want to implement this, it's
your call. For a patch to OpenVRML, though, I would like to see this
data structure remain consistent with the Pair Associative Container
concept[*], even if it doesn't fully model it.

[*] <http://www.sgi.com/tech/stl/PairAssociativeContainer.html>

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

[openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[<MSo...@ya...>]

Hi Braden

> I think I do not understand how your "view arrays" work. They are an
> array of viewer::object_id? How are they indexed?
> 
> Don't you need an associative array (of whatever implementation) in
> either case? It seems to me you either map node* to 
> viewer::object_id in
> the viewer, or you map viewer* to viewer::object_id in the node.

Those nodes in a scene that are creating references in the view get a
unique ID that is counted up from 1. The IDs can be managed by the
scene or browser and IDs should be recycled if a node is deleted, so
that the IDs are usually dense and can be used as direct array index.
What the array contains depends on the view, I would say. A GL view
might store GL list indices. A different view might store something
else. How do you like this concept?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/242 - Release Date:
26.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Wed, 2006-01-25 at 21:35 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > > I think a view is either coupled to the VRML view concept or free.
> > > 
> > Hm... I'm not entirely sold on that; but perhaps you're right.
> 
> I am not a VRML expert. I cannot judge this. It is just what I am
> doing, but my application is probably far away of the standard
> application.

I doubt I'll have a completely clear idea of the Right Thing until I've
gotten my hands dirty and reworked OpenVRML's navigation story.

In the meantime, the best I can do is see what smells right.

> > This does require a substantial rethinking of the interaction 
> > between=20
> > the node implementation and the viewer. Instead of the node 
> > knowing if=20
> > it's been rendered before, the viewer would keep track of that.
> 
> I don't think so. Just when the node creates a reference in the view,
> it gives the view its own ID and it is the job of the view to store
> its correpsonding data. When the node tells the view to render the
> reference it again gives its own ID and the view can retrieve the
> corresponding data. So instead of the view giving an ID to the node,
> the node gives an ID to the view. Actually this way, it is completely
> to the view how it stores the data it needs and different views can
> use different methods.

Yes. +1 on moving renderer-specific information out of the scene graph
and into the viewer implementation.

> > A std::map is not a hash map. It is a red-black tree. Lookup 
> > based on=20
> > pointers/integers is very efficient.
> 
> I think a red-black tree is even less efficient than a hash map if
> there are more than just a few indices in it (a hash map has like an
> array O(1) average time, while a read-black tree has O(1.5*log(n))
> time average performance with a lot of unpredictable jumping).

In practice the overhead imposed by the hash function muddies this a
bit.

But the data sets in question probably aren't large enough for any
difference to be noticeable. The major selling point of std::map is that
it's Just There. But I could be sold on a leaner alternative.

>  I would
> spend the memory for the indices in the nodes. This saves then the
> memory in the per view data structures. Assume you have 1000 nodes and
> 3 views. When you map this from node pointers using a red-black tree,
> you need 3 pointers (two next pointers, one key pointer) and a bool
> for the red/black and say 4 bytes for the stored GL-list index, which
> are 20 bytes (rounded up to alignment) per node and view. In the
> sample above this are 1000*3*20=60.000 bytes. When you store an index
> in the nodes, this are 4 bytes per node. In the view arrays you also
> need only 4 bytes for the GL-index. This are 1000*(3+1)*4 = 16.000
> bytes. A self growing array will waste a factor of sqrt(2) memory on
> average, so this would be really 1000*(3*1.41+1)*4~21.000 bytes. So a
> self growing array needs less memory and is faster.

I think I do not understand how your "view arrays" work. They are an
array of viewer::object_id? How are they indexed?

Don't you need an associative array (of whatever implementation) in
either case? It seems to me you either map node* to viewer::object_id in
the viewer, or you map viewer* to viewer::object_id in the node.

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

[openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[<MSo...@ya...>]

Hi Braden,

> > I think a view is either coupled to the VRML view concept or free.
> > 
> Hm... I'm not entirely sold on that; but perhaps you're right.

I am not a VRML expert. I cannot judge this. It is just what I am
doing, but my application is probably far away of the standard
application.

> This does require a substantial rethinking of the interaction 
> between=20
> the node implementation and the viewer. Instead of the node 
> knowing if=20
> it's been rendered before, the viewer would keep track of that.

I don't think so. Just when the node creates a reference in the view,
it gives the view its own ID and it is the job of the view to store
its correpsonding data. When the node tells the view to render the
reference it again gives its own ID and the view can retrieve the
corresponding data. So instead of the view giving an ID to the node,
the node gives an ID to the view. Actually this way, it is completely
to the view how it stores the data it needs and different views can
use different methods.

> A std::map is not a hash map. It is a red-black tree. Lookup 
> based on=20
> pointers/integers is very efficient.

I think a red-black tree is even less efficient than a hash map if
there are more than just a few indices in it (a hash map has like an
array O(1) average time, while a read-black tree has O(1.5*log(n))
time average performance with a lot of unpredictable jumping). I would
spend the memory for the indices in the nodes. This saves then the
memory in the per view data structures. Assume you have 1000 nodes and
3 views. When you map this from node pointers using a red-black tree,
you need 3 pointers (two next pointers, one key pointer) and a bool
for the red/black and say 4 bytes for the stored GL-list index, which
are 20 bytes (rounded up to alignment) per node and view. In the
sample above this are 1000*3*20=60.000 bytes. When you store an index
in the nodes, this are 4 bytes per node. In the view arrays you also
need only 4 bytes for the GL-index. This are 1000*(3+1)*4 = 16.000
bytes. A self growing array will waste a factor of sqrt(2) memory on
average, so this would be really 1000*(3*1.41+1)*4~21.000 bytes. So a
self growing array needs less memory and is faster.

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/240 - Release Date:
25.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

Michael S=F6gtrop wrote:
> Hi Braden,
>=20
> I think the views are not that much of a problem. In case you want to
> have multiple views, you do that for a reason and in this case you
> probably completely ignore the VRML view stuff (like I do). I think a
> view is either coupled to the VRML view concept or free.

Hm... I'm not entirely sold on that; but perhaps you're right.

Part of the problem in assessing this is that having the navigation=20
stuff so tightly embedded with the viewer simply isn't appropriate,=20
regardless of all this. It's one of the things that I've been planning=20
to address after 0.16.

> Regarding the storing of view dependent data in the nodes:
>=20
> I think it might be best to have an 'information item index' in the
> nodes and each view has a self-growing array of information items.

Hm... This might be the right approach. Though I don't think we need the=20
  "information item index" in the node; couldn't we just index on a=20
pointer to the node?

This does require a substantial rethinking of the interaction between=20
the node implementation and the viewer. Instead of the node knowing if=20
it's been rendered before, the viewer would keep track of that.

> This would be significantly more efficient than a hash-map (no hash
> code calculation, better cache locality). The information item indices
> are managed by the browser and can be recycled if a node is deleted.

A std::map is not a hash map. It is a red-black tree. Lookup based on=20
pointers/integers is very efficient.

Braden

[openvrml-develop] Re: Problem rendering from one browser into multiple/changing openvrml::gl::viewers

[<MSo...@ya...>]

Hi Braden,

I think the views are not that much of a problem. In case you want to
have multiple views, you do that for a reason and in this case you
probably completely ignore the VRML view stuff (like I do). I think a
view is either coupled to the VRML view concept or free.

Regarding the storing of view dependent data in the nodes:

I think it might be best to have an 'information item index' in the
nodes and each view has a self-growing array of information items.
This would be significantly more efficient than a hash-map (no hash
code calculation, better cache locality). The information item indices
are managed by the browser and can be recycled if a node is deleted.

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.21/236 - Release Date:
20.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [openvrml-develop] Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Sun, 2006-01-22 at 15:26 -0500, Braden McDaniel wrote:

> I think navigation-related stuff is going to be tricky. VRML has a
> notion of a "user view" that is an offset relative to the currently
> active Viewpoint node. It does not have a notion of more than one user
> view; so such a notion will need to be devised.

Or alternatively, the notion of the "user view" needs to remain
singular, but divorced from any single viewer. Maybe there needs to be a
single "primary" viewer at any given time to which the user view is
bound.

I'm just tossing out ideas here; I'm really not sure what the Right
Thing is yet.

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

Re: [openvrml-develop] Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Sun, 2006-01-22 at 12:07 -0500, Reed Hedges wrote:
> Can a node be linked to more than one scene object?

No.

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

Re: [openvrml-develop] Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

On Sun, 2006-01-22 at 10:56 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > I'd welcome a patch to fix the library to support this; 
> > however, it's a
> > nontrivial amount of work.
> 
> There would be several methods to solve this: 
> 
> 1.) have a function iterate the whole scene and reset all view
> dependent information
> 
> 2.) store a view id with view dependent information and reset it
> during rendering if the view doesn't match
> 
> 3.) Use some sort of container to store multiple view dependent
> informations per node.
> 
> 4.) Have a mode that doesn't use view dependent information at all
> (like the hack I tried with begin_object).
> 
> I think 1.) would be most efficient and simple, but it cannot be made
> inherently thread safe, so that rendering requests from multiple views
> need to be serialized with a semaphore. In my app the GUI is single
> threaded, so this wouldn't be a problem for me. I think this should be
> true for most apps.

The problem with threading makes this a nonstarter; but I don't think
this is particularly (time-) efficient either. As scene size and the
number of viewers increases, this could get pretty slow.

> 2.) is a bit trading speed for memory compared to 1.) and could be
> made thread safe but it would need an interlocked exchange function
> and if rendering really overlaps regularly, rendering speed will be
> degraded because the list IDs are constantly overwritten and not
> really used. I would then rather prefer 4.) so that you know what you
> get.

Yeah; this doesn't strike me as very efficient either, since viewer
dependent-information will not typically be coincident between more than
one viewer.

> 3.) is I think a bit heavy in terms of memory consumption.

Well, the std::map itself might be; but the things being stored
(pointers and integers) are not. I think this is what we want to do--use
std::map first for convenience, and potentially replace it if it's too
much of a pig.

> 4.) would allow inherently thread safe rendering but is of course far
> from optimal in terms of rendering speed.

Also a nonstarter.

> What do you think about this? 
> 
> Can you give me some hints on what to look out for (in addition to the
> GL list IDs)? Clearing the list IDs is a bit of work but should be
> straight forward, but I have no idea what else there might be.

I think navigation-related stuff is going to be tricky. VRML has a
notion of a "user view" that is an offset relative to the currently
active Viewpoint node. It does not have a notion of more than one user
view; so such a notion will need to be devised.

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

Re: [openvrml-develop] Problem rendering from one browser into multiple/changing openvrml::gl::viewers

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

Can a node be linked to more than one scene object?


Reed