quesa-develop — Mailing list for Quesa development

Re: RenderFastPathTriMesh: Triangle strip problem

[James W. W. <os...@jw...>]

On Oct 15, 2007, at 12:13 PM, Stefan Huber wrote:

> Your fix works well for Quesa OpenGL and Wireframe, thanks.
> Unfortunately Quesa Hiddenline still shows degenerated triangles.

I'm not too familiar with what the HiddenLine renderer is supposed to  
do, but I think I have fixed it.

Re: RenderFastPathTriMesh: Triangle strip problem

[Stefan H. <st...@to...>]

>On Oct 14, 2007, at 3:53 PM, Stefan Huber wrote:
>
>>  The combination of kQ3FillStyleEdges and kQ3BackfacingStyleBoth/Flip
>>  produces for large trimeshes (see kMinTrianglesToCache) junk lines
>>  when kQ3RendererPropertyAutomaticTriangleStrips is on and VBOs are
>>  used.
>>
>>  Removing QORenderer::Renderer::RenderFastPathTriMesh line 1010f
>>  (GetCachedTriangleStrip) temporarily "solves" the problem.
>>
>>  The error occurs with Quesa OpenGL when kQ3FillStyleEdges is on and
>>  with Quesa Wireframe and Hiddenline (Wireframe and  Hiddenline are
>>  using glPolygonMode( GL_FRONT_AND_BACK, GL_LINE )).
>
>
>This turned out to be pretty easy to figure out.  In order to create 
>a single triangle strip, the MakeStrip algorithm adds degenerate 
>triangles linking together separate strips.  In the usual filled 
>style, these degenerate triangles are not drawn, but in edge fill 
>style, they cause extra edges.
>
>I have committed a fix, which simply does not use triangle strips in
>the edge fill case.
>

Your fix works well for Quesa OpenGL and Wireframe, thanks. 
Unfortunately Quesa Hiddenline still shows degenerated triangles.

   Stefan
   http://www.topoi.ch

Re: RenderFastPathTriMesh: Triangle strip problem

[James W. W. <os...@jw...>]

On Oct 14, 2007, at 3:53 PM, Stefan Huber wrote:

> The combination of kQ3FillStyleEdges and kQ3BackfacingStyleBoth/Flip
> produces for large trimeshes (see kMinTrianglesToCache) junk lines
> when kQ3RendererPropertyAutomaticTriangleStrips is on and VBOs are
> used.
>
> Removing QORenderer::Renderer::RenderFastPathTriMesh line 1010f
> (GetCachedTriangleStrip) temporarily "solves" the problem.
>
> The error occurs with Quesa OpenGL when kQ3FillStyleEdges is on and
> with Quesa Wireframe and Hiddenline (Wireframe and  Hiddenline are
> using glPolygonMode( GL_FRONT_AND_BACK, GL_LINE )).


This turned out to be pretty easy to figure out.  In order to create  
a single triangle strip, the MakeStrip algorithm adds degenerate  
triangles linking together separate strips.  In the usual filled  
style, these degenerate triangles are not drawn, but in edge fill  
style, they cause extra edges.

I have committed a fix, which simply does not use triangle strips in  
the edge fill case.


> The Interactive renderer has its own backface culling: here all is ok.


Which has nothing to do with backface culling, only the fact that the  
IR never uses triangle strips.

Re: RenderFastPathTriMesh: Triangle strip problem

[James W. W. <os...@jw...>]

On Oct 14, 2007, at 3:53 PM, Stefan Huber wrote:

> The combination of kQ3FillStyleEdges and kQ3BackfacingStyleBoth/Flip
> produces for large trimeshes (see kMinTrianglesToCache) junk lines
> when kQ3RendererPropertyAutomaticTriangleStrips is on and VBOs are
> used.
>
> Removing QORenderer::Renderer::RenderFastPathTriMesh line 1010f
> (GetCachedTriangleStrip) temporarily "solves" the problem.
>
> The error occurs with Quesa OpenGL when kQ3FillStyleEdges is on and
> with Quesa Wireframe and Hiddenline (Wireframe and  Hiddenline are
> using glPolygonMode( GL_FRONT_AND_BACK, GL_LINE )).
>
> The Interactive renderer has its own backface culling: here all is ok.

Can you tell me how to see this problem in Geom Test?  With the Quesa  
logo (which has enough triangles), OpenGL renderer, and fill style  
edges, I don't see any obvious problem.

RenderFastPathTriMesh: Triangle strip problem

[Stefan H. <st...@to...>]

The combination of kQ3FillStyleEdges and kQ3BackfacingStyleBoth/Flip 
produces for large trimeshes (see kMinTrianglesToCache) junk lines 
when kQ3RendererPropertyAutomaticTriangleStrips is on and VBOs are 
used.

Removing QORenderer::Renderer::RenderFastPathTriMesh line 1010f 
(GetCachedTriangleStrip) temporarily "solves" the problem.

The error occurs with Quesa OpenGL when kQ3FillStyleEdges is on and 
with Quesa Wireframe and Hiddenline (Wireframe and  Hiddenline are 
using glPolygonMode( GL_FRONT_AND_BACK, GL_LINE )).

The Interactive renderer has its own backface culling: here all is ok.

   Stefan
   http://www.topoi.ch

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 13, 2007, at 1:03 AM, Sauro Agostini wrote:

> The other way could be to modify your optimizing code to copy the
> custom attributes of polygon and general polygons to the faces
> attributes of the meshes. What part of the code should I look for
> this modification?

Where exactly is the custom attribute?  Is it a vertex attribute, or  
does it belong to the attribute set of the geometry, or does it  
belong to a free-floating attribute set?

Re: Last Quesa is very slow

[Sauro A. <sag...@in...>]

>
>
>I don't understand why you need custom attributes, since they cannot 
>affect the rendering.

The custom attributes are for picking, selecting and modify.

The model is generated from an architectural model where the basic 
elements are walls, roofs, windows etc.  When the program generates 
the model, adds a custom attribute with some information to retrieve 
the original elements (layer, type of element and an index).
When the user click on the model in selection mode, the attribute 
indexes to the original element, the program generate a little model 
of it and the user can drag, double click, change the dimension etc.

>You could modify my programs to preserve the custom attributes.  Or 
>perhaps you could keep the original geometry around in a display
>group marked invisible.
>

Yes, I could save 2 different models, an optimized model for a fast 
navigation and the original model for picking, selecting and 
modifying.
The other way could be to modify your optimizing code to copy the 
custom attributes of polygon and general polygons to the faces 
attributes of the meshes. What part of the code should I look for 
this modification?

Thanks again.

Sauro
-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573 992930 
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 12, 2007, at 10:44 AM, Sauro Agostini wrote:

> Now it's very fast and the textures are OK. There is another problem
> with custom attributes.
> Any original polygons have a custom attribute.
> The final model is composed of meshes that includes the original
> polygons with the same characteristics.
> I find that the custom attribute of the last element of a certain
> type is assigned as a general mesh attribute.
> The triangles faces have an attribute 3, that should be
> AttributeTypeNormal, so it doesn't seem to contain the custom
> attribute of the original polygons.

I don't understand why you need custom attributes, since they cannot  
affect the rendering.

You could modify my programs to preserve the custom attributes.  Or  
perhaps you could keep the original geometry around in a display  
group marked invisible.

Re: Last Quesa is very slow

[Sauro A. <sag...@in...>]

>It wasn't the textures that were missing, it was the UV coordinates.  
>Your model had shading UVs, and I was looking for surface UVs.  I 
>have changed the merge functions to treat surface UVs and shading UVs
>as interchangeable.


Now it's very fast and the textures are OK. There is another problem 
with custom attributes.
Any original polygons have a custom attribute.
The final model is composed of meshes that includes the original 
polygons with the same characteristics.
I find that the custom attribute of the last element of a certain 
type is assigned as a general mesh attribute.
The triangles faces have an attribute 3, that should be 
AttributeTypeNormal, so it doesn't seem to contain the custom 
attribute of the original polygons.

Any suggestion?

Thanks,

Sauro Agostini
-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573 992930 
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 12, 2007, at 1:07 AM, Daniele Cavallini wrote:

> Wow! Very good optimization. I try it and it is very fast result.
> They are good for windows,too?

Yes, there is nothing platform-specific about it.


> James W. Walker ha scritto:
>> On Oct 11, 2007, at 11:31 AM, Sauro Agostini wrote:
>>
>>
>>>> DecomposeGeometries, like Q3Geometry_GetDecomposed, must be  
>>>> called in
>>>> a submitting loop.  When I tried it, I did it like this:
>>>>
>>>>
>>> After this modification I have the same results as you, but with a
>>> collateral effect if there are some textures.
>>>
>>> The little textured 3DMF file shows the problem:
>>>
>>> http://wwww.interstudio.net/quesa/3wallTexture.zip
>>>
>>> Textures and shaders are applied to groups and it seems that
>>> DecomposeGeometries (or LowerAttributesToGeometries?)  misses the
>>> textures, so after the optimization the model shows without  
>>> textures.
>>>
>>>
>>
>> It wasn't the textures that were missing, it was the UV coordinates.
>> Your model had shading UVs, and I was looking for surface UVs.  I
>> have changed the merge functions to treat surface UVs and shading UVs
>> as interchangeable.
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a  
>> browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Quesa-develop mailing list
>> Que...@li...
>> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>>
>>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Re: Last Quesa is very slow

[Daniele C. <dca...@in...>]

Wow! Very good optimization. I try it and it is very fast result.
They are good for windows,too?

James W. Walker ha scritto:
> On Oct 11, 2007, at 11:31 AM, Sauro Agostini wrote:
>
>   
>>> DecomposeGeometries, like Q3Geometry_GetDecomposed, must be called in
>>> a submitting loop.  When I tried it, I did it like this:
>>>
>>>       
>> After this modification I have the same results as you, but with a
>> collateral effect if there are some textures.
>>
>> The little textured 3DMF file shows the problem:
>>
>> http://wwww.interstudio.net/quesa/3wallTexture.zip
>>
>> Textures and shaders are applied to groups and it seems that
>> DecomposeGeometries (or LowerAttributesToGeometries?)  misses the
>> textures, so after the optimization the model shows without textures.
>>
>>     
>
> It wasn't the textures that were missing, it was the UV coordinates.   
> Your model had shading UVs, and I was looking for surface UVs.  I  
> have changed the merge functions to treat surface UVs and shading UVs  
> as interchangeable.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 11, 2007, at 11:31 AM, Sauro Agostini wrote:

>>
>>
>> DecomposeGeometries, like Q3Geometry_GetDecomposed, must be called in
>> a submitting loop.  When I tried it, I did it like this:
>>
>
>
> After this modification I have the same results as you, but with a
> collateral effect if there are some textures.
>
> The little textured 3DMF file shows the problem:
>
> http://wwww.interstudio.net/quesa/3wallTexture.zip
>
> Textures and shaders are applied to groups and it seems that
> DecomposeGeometries (or LowerAttributesToGeometries?)  misses the
> textures, so after the optimization the model shows without textures.
>

It wasn't the textures that were missing, it was the UV coordinates.   
Your model had shading UVs, and I was looking for surface UVs.  I  
have changed the merge functions to treat surface UVs and shading UVs  
as interchangeable.

accelerated offscreen drawing on Windows (was Re: Problem with shadow render opengl)

[James W. <ja...@fr...>]

With a few changes I just committed, I got hardware-accelerated 
offscreen rendering working on Windows, including shadows and per-pixel 
lighting.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Last Quesa is very slow

[Sauro A. <sag...@in...>]

>
>
>DecomposeGeometries, like Q3Geometry_GetDecomposed, must be called in
>a submitting loop.  When I tried it, I did it like this:
>


After this modification I have the same results as you, but with a 
collateral effect if there are some textures.

The little textured 3DMF file shows the problem:

http://wwww.interstudio.net/quesa/3wallTexture.zip

Textures and shaders are applied to groups and it seems that 
DecomposeGeometries (or LowerAttributesToGeometries?)  misses the 
textures, so after the optimization the model shows without textures.

Sauro Agostini

-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573 992930 
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: Long time in TriMeshOptimizer

[Roch M. C. <ro...@ro...>]

Adding the vertex normals did it!

Thanks!

Roch

On 9-Oct-07, at 10:48 PM, James Walker wrote:

> Roch M. Comeau wrote:
>> Hi Again,
>>
>> I found the headers describing TriMeshOptimizer and think adding
>> vertex normals (I already had face normals) might help, and hopefuly
>> it will be faster for me to calculate it on the fly while building  
>> the
>> mesh than have to have TriMeshOptimizer calculate it after.
>>
>> Any other comments welcome.
>
> Yes, providing your own normals will make it unnecessary for the
> renderer to optimize the geometry.
>
> -- 
>   James W. Walker, Innoventive Software LLC
>   <http://www.frameforge3d.com/>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>

Re: Long time in TriMeshOptimizer

[James W. <ja...@fr...>]

Roch M. Comeau wrote:
> Hi Again,
> 
> I found the headers describing TriMeshOptimizer and think adding  
> vertex normals (I already had face normals) might help, and hopefuly  
> it will be faster for me to calculate it on the fly while building the  
> mesh than have to have TriMeshOptimizer calculate it after.
> 
> Any other comments welcome.

Yes, providing your own normals will make it unnecessary for the 
renderer to optimize the geometry.

-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Long time in TriMeshOptimizer

[Roch M. C. <ro...@ro...>]

Hi Again,

I found the headers describing TriMeshOptimizer and think adding  
vertex normals (I already had face normals) might help, and hopefuly  
it will be faster for me to calculate it on the fly while building the  
mesh than have to have TriMeshOptimizer calculate it after.

Any other comments welcome.

Chers,

Roch Comeau

On 9-Oct-07, at 9:42 PM, Roch M. Comeau wrote:

> Hello,
>
> I recently made a small change in how I implemented a marching cubes  
> algorithm to generate a smoother "skin" segmentation from MR image  
> data (see attachments). The change did not alter the number of  
> triangles (about 200k) but did increase the smoothness quite a lot,  
> and more importantly for me, more accurate normals. The side-effect  
> I encountered was a dramatic increase in time to render the image  
> for the first time. When I submit the old skin for rendering for the  
> first time, there is an almost imperceptible pause before rendering  
> (about 1 second). When I submit the second one, I get a 60 second  
> delay before it appears. My program is unresponsive (spinning wheel)  
> until it completes so this is not desired. I ran it under Shark and  
> found that it spends its time in TriMeshOptimizer and mainly in  
> ArePointsSImilar and Q3FastVector3D_Dot within the optimizer.
>
> The old skin had a lot of polygons that were co-planar while the  
> smoother one has more variation in the orientations of the  
> triangles, if that helps. The 3dmf files are almost equal in size  
> (about 11MB) and once the skin has been rendered once, rotates in  
> real time. When I reload the image from file, it also displays  
> immediately the first time.
>
> Any thoughts? I really want this nice smooth skin, but a 60 second  
> pause (vs. 1 second) is a huge hit.
>
> Thanks,
>
> Roch Comeau
> Rogue Research INc.
>
> <New Skin.jpg><Old  
> Skin 
> .jpg 
> > 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop

Long time in TriMeshOptimizer

[Roch M. C. <ro...@ro...>]

Hello,

I recently made a small change in how I implemented a marching cubes  
algorithm to generate a smoother "skin" segmentation from MR image  
data (see attachments). The change did not alter the number of  
triangles (about 200k) but did increase the smoothness quite a lot,  
and more importantly for me, more accurate normals. The side-effect I  
encountered was a dramatic increase in time to render the image for  
the first time. When I submit the old skin for rendering for the first  
time, there is an almost imperceptible pause before rendering (about 1  
second). When I submit the second one, I get a 60 second delay before  
it appears. My program is unresponsive (spinning wheel) until it  
completes so this is not desired. I ran it under Shark and found that  
it spends its time in TriMeshOptimizer and mainly in ArePointsSImilar  
and Q3FastVector3D_Dot within the optimizer.

The old skin had a lot of polygons that were co-planar while the  
smoother one has more variation in the orientations of the triangles,  
if that helps. The 3dmf files are almost equal in size (about 11MB)  
and once the skin has been rendered once, rotates in real time. When I  
reload the image from file, it also displays immediately the first time.

Any thoughts? I really want this nice smooth skin, but a 60 second  
pause (vs. 1 second) is a huge hit.

Thanks,

Roch Comeau
Rogue Research INc.

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 9, 2007, at 7:59 AM, Sauro Agostini wrote:

>>
>> * The original farmhouse ran at about 6 FPS.
>> * With extra references removed (the RemoveExtraReferences function),
>> the speed was about 60 FPS.
>>
>> * With some more algorithms, I got the speed up to about 370 FPS.
>> The sequence of algorithms I used was:
>>
>> RemoveExtraReferences
>> DecomposeGeometries
>> LowerAttributesToGeometries
>> FlattenHierarchy
>> OptimizeTriMeshes
>> MergeTriMeshes
>
>
> Thanks a lot for your algorithms.
>
> There was a bug in the export 3DMF function of my application, so  
> there were more submitting of the same models.
>
> I tried to add all the other optimization functions, but I didn't  
> get your results.
>
>
> I added the following code to the Geom test example, after  
> importing a model:
>
>         RemoveExtraReferences(notOptimizedModel);
>         DecomposeGeometries( notOptimizedModel,theView );
>         LowerAttributesToGeometries( notOptimizedModel);
>         theModel=(TQ3GroupObject) FlattenHierarchy 
> (notOptimizedModel,0 );
>         OptimizeTriMeshes(theModel);
>         MergeTriMeshes( theModel);
>
>
> Working on the same 3dmf file that I sent you I have the following  
> results (on an iMac Intel 2 core Duo)
>
> Without optimization               18 FPS
> With extra references removed     155 FPS
> With all the algorithms           178 FPS
>
> Maybe didn't I apply the algorithms correctly?

DecomposeGeometries, like Q3Geometry_GetDecomposed, must be called in  
a submitting loop.  When I tried it, I did it like this:

	Q3View_StartBoundingBox( theView, kQ3ComputeBoundsApproximate );
	Qut_SubmitDefaultState(theView);
	DecomposeGeometries( gSceneGeometry, theView );
	Q3View_EndBoundingBox( theView, &dummyBounds );

Re: Last Quesa is very slow

[Sauro A. <sag...@in...>]

>
>* The original farmhouse ran at about 6 FPS.
>
>* With extra references removed (the RemoveExtraReferences function), 
>the speed was about 60 FPS.
>
>* With some more algorithms, I got the speed up to about 370 FPS.  
>The sequence of algorithms I used was:
>
>RemoveExtraReferences
>DecomposeGeometries
>LowerAttributesToGeometries
>FlattenHierarchy
>OptimizeTriMeshes
>MergeTriMeshes
>


Thanks a lot for your algorithms.

There was a bug in the export 3DMF function of my application, so 
there were more submitting of the same models.

I tried to add all the other optimization functions, but I didn't get 
your results.


I added the following code to the Geom test example, after importing a model:

	RemoveExtraReferences(notOptimizedModel);
	DecomposeGeometries( notOptimizedModel,theView );
	LowerAttributesToGeometries( notOptimizedModel);
	theModel=(TQ3GroupObject) FlattenHierarchy(notOptimizedModel,0 );
	OptimizeTriMeshes(theModel);
	MergeTriMeshes( theModel);


Working on the same 3dmf file that I sent you I have the following 
results (on an iMac Intel 2 core Duo)

Without optimization               18 FPS
With extra references removed     155 FPS
With all the algorithms           178 FPS

Maybe didn't I apply the algorithms correctly?

Thank you again,

Sauro Agostini
-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.      Tel + 39 0573 99291   Fax   + 39 0573 992930 
| |__ |  Piazza Monteoliveto 6a                    http://www.interstudio.net
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Another RayShade problem

[Roger H. <rog...@mi...>]

In our interior design program, Microspot Interiors, we set our  
ceilings to back face removed, so that inside the room you can see  
them, but above the room you can see through them into the room. This  
does not seem to work with RayShade. I understand that they must be  
taken into account for reflections, but would it be possible for this  
to be made to work? If so, any pointers on what needs to be changed  
would be useful.

Roger.

Re: Last Quesa is very slow

[James W. W. <os...@jw...>]

On Oct 5, 2007, at 11:01 AM, James Walker wrote:

> Even after this change, I think there is still much room for  
> improvement
> in your farmhouse.  I am thinking of writing up some algorithms to
> modify Quesa groups in various ways, such as merging TriMeshes.

I've now committed my algorithms in SDK/Extras/Utility Sources/ 
Mutating Algorithms.

I did some speed tests with a release build of Geom Test on my  
PowerBook.

* The original farmhouse ran at about 6 FPS.

* With extra references removed (the RemoveExtraReferences function),  
the speed was about 60 FPS.

* With some more algorithms, I got the speed up to about 370 FPS.   
The sequence of algorithms I used was:

RemoveExtraReferences
DecomposeGeometries
LowerAttributesToGeometries
FlattenHierarchy
OptimizeTriMeshes
MergeTriMeshes

Re: Last Quesa is very slow

[James W. <ja...@fr...>]

Sauro Agostini wrote:
>>
>> Anyway, you need to improve your model.  The farmhouse model has
>> multiple references to various groups.  Of course in some cases multiple
>> references can make sense, for instance if the references are subject to
>> different transformations, but in this case the multiple references are
>> just siblings in a group.  That is, you're rendering things multiple
>> times for no apparent reason.  When I removed the multiple references,
>> the model rendered almost 10 times faster with no apparent change in
>> appearance.
> 
> 
> Can you send me the modified model? It could be very useful for me, I 
> tried to remove some references from the 3DMF file, but the 
> appearance was different.
> 
> Thank you in advance.
> 
> Sauro Agostini

(model attached in private mail, not in the list)


Here is the code I used to remove the extra references.

	TQ3GroupPosition	pos, nextPos;
	TQ3Object	prevMember = NULL;
	TQ3Object	curMember;
	
	Q3Group_GetFirstPosition( theGroup, &pos );
	while (pos != NULL)
	{
		nextPos = pos;
		Q3Group_GetNextPosition( theGroup, &nextPos );
		Q3Group_GetPositionObject( theGroup, pos, &curMember );
		Q3Object_Dispose( curMember );	// the group still holds a ref
		if (curMember == prevMember)
		{
			curMember = Q3Group_RemovePosition( theGroup, pos );
			Q3Object_Dispose( curMember );
		}
		else
		{
			prevMember = curMember;
		}
		pos = nextPos;
	}


Even after this change, I think there is still much room for improvement
in your farmhouse.  I am thinking of writing up some algorithms to
modify Quesa groups in various ways, such as merging TriMeshes.
-- 
    James W. Walker, Innoventive Software LLC
    <http://www.frameforge3d.com/>

Re: Last Quesa is very slow

[Sauro A. <sag...@in...>]

>
>
>Anyway, you need to improve your model.  The farmhouse model has
>multiple references to various groups.  Of course in some cases multiple
>references can make sense, for instance if the references are subject to
>different transformations, but in this case the multiple references are
>just siblings in a group.  That is, you're rendering things multiple
>times for no apparent reason.  When I removed the multiple references,
>the model rendered almost 10 times faster with no apparent change in
>appearance.


Can you send me the modified model? It could be very useful for me, I 
tried to remove some references from the 3DMF file, but the 
appearance was different.

Thank you in advance.

Sauro Agostini
-- 
-----------------------------------------------------------------------------
  _ ___
|_| __|  Interstudio S.r.l.              Tel 0573 99291     Fax   0573 992930 
| |__ |  Piazza Monteoliveto 6a          http://www.interstudio.net/home.html
|_____|  I-51100 Pistoia Italy             mailto:int...@in...
-----------------------------------------------------------------------------

Re: Export 3dmf text file

[James W. W. <os...@jw...>]

On Oct 4, 2007, at 8:41 AM, Daniele Cavallini wrote:

> Is it possible to export a model in a 3D metafile mode text ?

Sorry, no.  That is bug 902977.