quesa-develop — Mailing list for Quesa development

Re: Announcing new OpenGL renderer

[Jose' C. <cru...@ce...>]

Il giorno 09/feb/07, alle ore 21:27, James Walker ha scritto:

>>
>> Your renderer is valid only with optimized trimeshes?
>
> Well, I've certainly concentrated on the fast path.  But I can do some
> automatic optimization the way the IR does.  Stay tuned...

Not every thing can be everything for everyone...

I've no problem with the Quesa renderer speed, so don't worry for me,  
concentrate in your needs...


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Announcing new OpenGL renderer

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

Jose' Cruanyes wrote:
> Il giorno 09/feb/07, alle ore 20:13, James Walker ha scritto:
> 
>> That model lacks vertex normals, so it's not on the fast path.  It  
>> also
>> has lots of TriMeshes for no apparent reason, that is, they could be
>> merged into one TriMesh.
> 
> 
> I've no control with the models used in my program,
> Your renderer is valid only with optimized trimeshes?

Well, I've certainly concentrated on the fast path.  But I can do some 
automatic optimization the way the IR does.  Stay tuned...
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Announcing new OpenGL renderer

[Jose' C. <cru...@ce...>]

Il giorno 09/feb/07, alle ore 20:13, James Walker ha scritto:

> That model lacks vertex normals, so it's not on the fast path.  It  
> also
> has lots of TriMeshes for no apparent reason, that is, they could be
> merged into one TriMesh.


I've no control with the models used in my program,
Your renderer is valid only with optimized trimeshes?

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Announcing new OpenGL renderer

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

James Walker wrote:

> I would expect the Quesa logo to be significantly faster, especially if 
> you increase the number of triangles by setting the subdivision style to 
> constant (50, 50).
> 
> I'll do some testing on Windows.

I tried Geom Test on Windows.  With the default subdivision style, 
you're right, the speed is about the same on the Quesa logo.  But with 
constant (50, 50) subdivision, I see a jump from 43 FPS to 83 FPS.

There seems to be a limit on the frame rate you can see in Geom Test on 
Windows.  The SetTimer call asks for a timer message every 2 
milliseconds, giving a theoretical maximum of 500 FPS, but I never seem 
to see more than 100 FPS.  The SetTimer docs say that on Windows 2000, 
the timer interval cannot be less than USER_TIMER_MINIMUM, but I can't 
find where USER_TIMER_MINIMUM is defined.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Announcing new OpenGL renderer

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

Jose' Cruanyes wrote:
> Il giorno 09/feb/07, alle ore 19:27, James Walker ha scritto:
> 
>> Tell me more about how you're testing.  What platform?  What test app?
>> Does the machine have a video card with VRAM, and does it support the
>> extension GL_ARB_vertex_buffer_object?
> 
> Athlon 3200 - Win 2000 - 1Gb Ram
> ATI Radeon 9200 256Mb VRam
> 
> Quesa compiled on CW Windows 8.3
> 
> in Geom Test, it runs more or less like the old in quesa logo and  
> multibox

I would expect the multibox test to be only a little faster, for reasons 
explained in my performance notes.

I would expect the Quesa logo to be significantly faster, especially if 
you increase the number of triangles by setting the subdivision style to 
constant (50, 50).

I'll do some testing on Windows.

After the 2 changes I just committed, transparency is working for me.

> I've more complex models that runs near 20x slower!!!
> 
> I've put a particularly bad model at
> <http://cremona.cegroup.it/download/CorniceOro.zip> (2.8 Mb)

That model lacks vertex normals, so it's not on the fast path.  It also 
has lots of TriMeshes for no apparent reason, that is, they could be 
merged into one TriMesh.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Announcing new OpenGL renderer

[Jose' C. <cru...@ce...>]

Il giorno 09/feb/07, alle ore 19:27, James Walker ha scritto:

> Tell me more about how you're testing.  What platform?  What test app?
> Does the machine have a video card with VRAM, and does it support the
> extension GL_ARB_vertex_buffer_object?

Athlon 3200 - Win 2000 - 1Gb Ram
ATI Radeon 9200 256Mb VRam

Quesa compiled on CW Windows 8.3

in Geom Test, it runs more or less like the old in quesa logo and  
multibox

I've more complex models that runs near 20x slower!!!

I've put a particularly bad model at
<http://cremona.cegroup.it/download/CorniceOro.zip> (2.8 Mb)

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Announcing new OpenGL renderer

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

Jose' Cruanyes wrote:

> In my firsts test I can't note any improvement over the old one...
> It seems slower in all my tests, and it doesn't handle transparencies...
> what I'm doing wrong?

I do see a problem with transparency, which I'll work on now.  But other 
than that, I don't understand.  There can be a little more time when an 
object is first loaded, mainly to compute the triangle strip.  But once 
things settle down, I see improvements anywhere from 15% to 400%.

Tell me more about how you're testing.  What platform?  What test app? 
Does the machine have a video card with VRAM, and does it support the 
extension GL_ARB_vertex_buffer_object?
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Announcing new OpenGL renderer

[Jose' C. <cru...@ce...>]

Il giorno 09/feb/07, alle ore 03:37, James Walker ha scritto:

> I've committed the code for my new renderer.  I updated the  
> projects for
>   CodeWarrior and Xcode/Carbon, leaving Xcode/Cocoa, Visual Studio,  
> and
> the Unix makefile for others to handle.


In my firsts test I can't note any improvement over the old one...
It seems slower in all my tests, and it doesn't handle transparencies...
what I'm doing wrong?

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Announcing new OpenGL renderer

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

I've committed the code for my new renderer.  I updated the projects for 
  CodeWarrior and Xcode/Carbon, leaving Xcode/Cocoa, Visual Studio, and 
the Unix makefile for others to handle.


Question: Should the triangle-strip computing function be exposed as a 
public API, and if so, which header should it go in?


Visible Differences from Interactive Renderer

* There is no distinction between the "both" and "flip" backfacing
   styles.  Both cases use normal OpenGL two-sided lighting.

* Geometries of dimension less than 2 (Point, Line, PolyLine,
   Ellipse, NURBCurve) are unaffected by the direction of the light.

* Textures of pixel type kQ3PixelTypeARGB16 are treated differently.
   With the default linear texture filtering, you will see a smooth
   transition from transparent to opaque.


Performance Notes

* In order for a TriMesh to be on the "fast path" for the OpenGL
   renderer,

   * it must be a retained object
   * it must have vertex normals
   * it must not have color or texture with transparency
   * it must not have per-face colors (unless per-vertex colors are also
     present)
   * it must not have per-face textures

* Per-face normals on TriMeshes are ignored.

* You will get better performance with a few large TriMeshes than
   with many small ones.  The "MultiBox" test in the Geom Test sample
   is a particularly bad case, having 4000 TriMeshes with 2 triangles
   each.

* A fast-path TriMesh with more than 500 faces will be cached as a
   vertex buffer object when the hardware supports it, and otherwise
   as a display list.

* When a fast-path TriMesh has more than 500 faces, we compute a
   triangle strip for it and cache the strip in an object property.

* This renderer gives much more of a performance boost when the video
   card has actual VRAM rather than shared system memory.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: How I find memory leak?

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

I found and resolved. Luckily there is the function 
"Q3Memory_StartRecording".
I think it is important a little of documentation just for to know it exist.
James Walker wrote:
> Daniele Cavallini wrote:
>   
>> It is a very useful function.
>> I set Q3_DEBUG and  I set "Q3Memory_StartRecording()"  at start of 
>> application and I obtain a file like this:
>>
>> /========== START DUMP Fri Feb 02 18:15:06 2007 Q3Exit ==========
>> InteractiveRenderer (033535EC)   2
>> Set (03353804)   1
>> Quesa:DepthBitsElement (033538DC)
>> Quesa:Slab (03353A64)
>> Quesa:Slab (03353ACC)
>> Quesa:Slab (03353B34)
>> Quesa:Slab (03353B9C)
>> View (03354964)
>> AttributeSet (03354A7C)   1
>> Win32DCDrawContext (03354B54)   1
>> ViewAngleCamera (03354C1C)   1
>> PhongIllumination (03354E0C)   1
>> LightGroup (03354E94)   1
>> AmbientLight (03354EFC)   1
>> PointLight (03354FBC)   1
>> FillStyle (0039FCD4)   1
>> InterpolationStyle (03354CC4)   1
>> BackfacingStyle (03354D2C)   1
>> OrderedDisplayGroup (033557C4)   1
>> DisplayGroup (03355E1C)   1
>> AttributeSet (03355EA4)   3
>> Myatt (03355F7C)
>> Polygon (03356084)   1
>> AttributeSet (0335625C)   1
>> TriMesh (033566AC)   1
>> TriMesh (03356EEC)   1
>> Set (03356C44)   1
>> Quesa:IR:OptTriMeshCache (03356D1C)
>> ========== END DUMP ==========/
>>
>> Are all memory leak?
>>     
>
> The fact that no reference count is greater than 2 indicates that it is 
> not a serious leak, you probably just neglected to dispose all objects 
> before calling Q3_Exit.  Furthermore, they are not all independent.  For 
> example, once you stop leaking renderers, the Slab and DepthBitsElement 
> leaks will probably go away.
>   

Re: Anyone use edges in TriMeshes?

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

Since the QD3D manual doesn't say what edges are supposed to do, I've  
been unclear on the concept.  Let's see if I have it right yet.  When  
rendering in polygon-fill mode, the edges do nothing.  When rendering  
in edge-fill mode, you see the explicitly specified edges instead of  
all the poiygon edges.  Right?

Now, how about the attributes?  If diffuse color is specified for  
both an edge and its vertices, which wins?  How about if neither  
edges nor vertices specifies color, can an edge inherit a color from  
a parent polygon, and if so, what if the parents disagree?

I tried a TriMesh with edges in Geom Test in Classic mode, and as  
soon as I turned on edge fill mode, it froze.

Re: Anyone use edges in TriMeshes?

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

On 2 Feb, 2007, at 22:02, Jose' Cruanyes wrote:

>
> Il giorno 02/feb/07, alle ore 20:19, Roger Holmes ha scritto:
>
>> Currently it generates nothing and cube actually
>> disappear on wire frame, which is something we have
>> been apologising for for the last few years. We try
>> to get our users not use the cuboid data structure
>> for this reason and use a group of six polygons instead.
>
>
> if this fact is so important to you, why it's not still implemented?
> I think that should be almost trivial to add the edges to the cube
> decomposition procedure,,,
>
> I'm missing something?

No, you are right. I will try to get around to it.

Roger.

[ quesa-Bugs-1194603 ] Transparency problem with rasterize camera transforms

[SourceForge.net <no...@so...>]

Bugs item #1194603, was opened at 2005-05-03 10:40
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1194603&group_id=45158

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Frank Condello (pox)
Assigned to: James W. Walker (jwwalker)
Summary: Transparency problem with rasterize camera transforms

Initial Comment:
Transparent triangles with Z coordinates other than zero aren't drawn 
when using rasterize camera transforms. The problem lies in 
ir_geom_transparent_add, where triangles "behind" the camera are 
culled. Rasterize transforms invert Z, which is likely confusing the 
culling check.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2007-02-02 19:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: James W. Walker (jwwalker)
Date: 2007-01-19 18:06

Message:
Logged In: YES 
user_id=433183
Originator: NO

I think this was probably fixed by a change to
e3transform_camera_rasterize_submit in July 2006.  Since no test case was
provided, I'll mark this fixed unless I hear differently.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442052&aid=1194603&group_id=45158

Re: Anyone use edges in TriMeshes?

[Jose' C. <cru...@ce...>]

Il giorno 02/feb/07, alle ore 20:19, Roger Holmes ha scritto:

> Currently it generates nothing and cube actually
> disappear on wire frame, which is something we have
> been apologising for for the last few years. We try
> to get our users not use the cuboid data structure
> for this reason and use a group of six polygons instead.


if this fact is so important to you, why it's not still implemented?
I think that should be almost trivial to add the edges to the cube  
decomposition procedure,,,

I'm missing something?

Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Anyone use edges in TriMeshes?

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

On 2 Feb, 2007, at 16:54, James W. Walker wrote:

>> If the old renderer is continuing to be supported then fine, but if
>> the
>> new renderer is going to become a replacement then I would like
>> TriMesh edges supported at least when the Fill Style is
>> kQ3FillStyleEdges.
>>
>> Much less important, but it would be nice if vertices could still be
>> supported when Fill Style is kQ3FillStylePoints.
>
> I'm not sure we're on the same wavelength.  Of course
> kQ3FillStyleEdges and kQ3FillStylePoints will be supported.  I'm
> talking about the edges that can be specified explicitly in
> TQ3TriMeshData.

This is my wavelength:

In the caching code everything gets reduced to either markers,
points, lines, trinagles or trimeshes. Most things become trimeshes.
Trimeshes have explicit edges. There are no implicit edges.
We use kQ3FillStyleEdges to give the users a wire frame view,
and we also use an embeded kQ3FillStyleEdges to show
a wire frame on top of a geometry when editing certain geometries
so the user can see the edges and vertices he can move. This
is done in a view where all the other geometries  are drawn
solid. If you do not implement edges in Trimeshes, none of
this will work with your new renderer and I will have to use the
old one, which is fine as long as it is still supported.

Trimeshes have three collections of objects: vertices, edges
and triangles. The triangles themselves do themselves
generate lines, otherwise as most triangles abut other
triangles, for each edge it would get drawn twice, once
for each triangle either side of it. This would I think
double the size of the data passed to OpenGL when
doing a wire frame render, though of course this is
quite fast anyway, but when a cube is cached as a
trimesh, it SHOULD (though not currently) generate
edges for the twelve edges of the cube and should
generate twelve triangles, but it should not generate
edges along the split of each square face of the cube.
Currently it generates nothing and cube actually
disappear on wire frame, which is something we have
been apologising for for the last few years. We try
to get our users not use the cuboid data structure
for this reason and use a group of six polygons instead.

Similarly, in wire frame, do you really want to see the
tesselation of a polygon or just the edges?

Roger.

Re: How I find memory leak?

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

Daniele Cavallini wrote:
> It is a very useful function.
> I set Q3_DEBUG and  I set "Q3Memory_StartRecording()"  at start of 
> application and I obtain a file like this:
> 
> /========== START DUMP Fri Feb 02 18:15:06 2007 Q3Exit ==========
> InteractiveRenderer (033535EC)   2
> Set (03353804)   1
> Quesa:DepthBitsElement (033538DC)
> Quesa:Slab (03353A64)
> Quesa:Slab (03353ACC)
> Quesa:Slab (03353B34)
> Quesa:Slab (03353B9C)
> View (03354964)
> AttributeSet (03354A7C)   1
> Win32DCDrawContext (03354B54)   1
> ViewAngleCamera (03354C1C)   1
> PhongIllumination (03354E0C)   1
> LightGroup (03354E94)   1
> AmbientLight (03354EFC)   1
> PointLight (03354FBC)   1
> FillStyle (0039FCD4)   1
> InterpolationStyle (03354CC4)   1
> BackfacingStyle (03354D2C)   1
> OrderedDisplayGroup (033557C4)   1
> DisplayGroup (03355E1C)   1
> AttributeSet (03355EA4)   3
> Myatt (03355F7C)
> Polygon (03356084)   1
> AttributeSet (0335625C)   1
> TriMesh (033566AC)   1
> TriMesh (03356EEC)   1
> Set (03356C44)   1
> Quesa:IR:OptTriMeshCache (03356D1C)
> ========== END DUMP ==========/
> 
> Are all memory leak?

The fact that no reference count is greater than 2 indicates that it is 
not a serious leak, you probably just neglected to dispose all objects 
before calling Q3_Exit.  Furthermore, they are not all independent.  For 
example, once you stop leaking renderers, the Slab and DepthBitsElement 
leaks will probably go away.
-- 
   James W. Walker, Innoventive Software LLC
   <http://www.frameforge3d.com/>

Re: Anyone use edges in TriMeshes?

[Kevin M. <mat...@ar...>]

On Fri, 2 Feb 2007 10:00:17 -0700, jo...@st... wrote:
> I can certainly see some uses for that -- but I don't have any
> immediate need for it myself.  If it holds up your renderer, I'd say
> leave it out, and consider adding it in later if users request it
> (unless supporting it would require a fundamentally different approach).

Well put, thanks!

- Kevin



    http://www.Artifice.com . digital media in design and building
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
    Artifice, Inc.                      ...the way of architecture
    http://www.archiplanet.org
    http://www.greatbuildings.com
    http://www.designcommunity.com
    http://www.architectureweek.com
    541.345.7421 vox . 541.345.7438 fax . 800.203.8324 US toll free
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+

Re: How I find memory leak?

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

It is a very useful function.
I set Q3_DEBUG and  I set "Q3Memory_StartRecording()"  at start of 
application and I obtain a file like this:

/========== START DUMP Fri Feb 02 18:15:06 2007 Q3Exit ==========
InteractiveRenderer (033535EC)   2
Set (03353804)   1
Quesa:DepthBitsElement (033538DC)
Quesa:Slab (03353A64)
Quesa:Slab (03353ACC)
Quesa:Slab (03353B34)
Quesa:Slab (03353B9C)
View (03354964)
AttributeSet (03354A7C)   1
Win32DCDrawContext (03354B54)   1
ViewAngleCamera (03354C1C)   1
PhongIllumination (03354E0C)   1
LightGroup (03354E94)   1
AmbientLight (03354EFC)   1
PointLight (03354FBC)   1
FillStyle (0039FCD4)   1
InterpolationStyle (03354CC4)   1
BackfacingStyle (03354D2C)   1
OrderedDisplayGroup (033557C4)   1
DisplayGroup (03355E1C)   1
AttributeSet (03355EA4)   3
Myatt (03355F7C)
Polygon (03356084)   1
AttributeSet (0335625C)   1
TriMesh (033566AC)   1
TriMesh (03356EEC)   1
Set (03356C44)   1
Quesa:IR:OptTriMeshCache (03356D1C)
========== END DUMP ==========/

Are all memory leak?


James W. Walker ha scritto:
> On Feb 2, 2007, at 5:25 AM, Daniele Cavallini wrote:
>
>   
>> I am searching a memory leak in my application.In TQ3Status E3Exit 
>> (void)
>> function I read:
>>
>> Q3Memory_DumpRecording( "Quesa-leaks.txt", "Q3Exit" );
>>
>> Can it useful for me? How I can activate? I don't find documentaion
>> about it. Have you some suggest for me?
>>     
>
> To use it, you need a copy of Quesa that has been compiled with the  
> macro Q3_DEBUG set to 1.  It will produce a text file listing the  
> types and numbers of leaked references.  In the Mac CFM case, it also  
> shows backtraces.
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop
>
>   

Re: How I find memory leak?

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

On Feb 2, 2007, at 5:25 AM, Daniele Cavallini wrote:

> I am searching a memory leak in my application.In TQ3Status E3Exit 
> (void)
> function I read:
>
> Q3Memory_DumpRecording( "Quesa-leaks.txt", "Q3Exit" );
>
> Can it useful for me? How I can activate? I don't find documentaion
> about it. Have you some suggest for me?

To use it, you need a copy of Quesa that has been compiled with the  
macro Q3_DEBUG set to 1.  It will produce a text file listing the  
types and numbers of leaked references.  In the Mac CFM case, it also  
shows backtraces.

Re: Anyone use edges in TriMeshes?

[<jo...@st...>]

On Feb 02, 2007, at 16:54 UTC, James W. Walker wrote:

> I'm not sure we're on the same wavelength.  Of course  
> kQ3FillStyleEdges and kQ3FillStylePoints will be supported.  I'm  
> talking about the edges that can be specified explicitly in  
> TQ3TriMeshData.

Right -- this would be used, for example, when displaying models in
wireframe mode, if you want to omit edges between two coplanar
triangles.  Right?

I can certainly see some uses for that -- but I don't have any
immediate need for it myself.  If it holds up your renderer, I'd say
leave it out, and consider adding it in later if users request it
(unless supporting it would require a fundamentally different approach).

HTH,
- Joe

--
Joe Strout -- jo...@st...
Verified Express, LLC     "Making the Internet a Better Place"
http://www.verex.com/

Re: Anyone use edges in TriMeshes?

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

On Feb 2, 2007, at 4:06 AM, Roger Holmes wrote:

> If the old renderer is continuing to be supported then fine, but if  
> the
> new renderer is going to become a replacement then I would like
> TriMesh edges supported at least when the Fill Style is
> kQ3FillStyleEdges.
>
> Much less important, but it would be nice if vertices could still be
> supported when Fill Style is kQ3FillStylePoints.

I'm not sure we're on the same wavelength.  Of course  
kQ3FillStyleEdges and kQ3FillStylePoints will be supported.  I'm  
talking about the edges that can be specified explicitly in  
TQ3TriMeshData.

How I find memory leak?

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

I am searching a memory leak in my application.In TQ3Status E3Exit(void) 
function I read:

Q3Memory_DumpRecording( "Quesa-leaks.txt", "Q3Exit" );

Can it useful for me? How I can activate? I don't find documentaion 
about it. Have you some suggest for me?

Re: Anyone use edges in TriMeshes?

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

If the old renderer is continuing to be supported then fine, but if the
new renderer is going to become a replacement then I would like
TriMesh edges supported at least when the Fill Style is
kQ3FillStyleEdges.

Much less important, but it would be nice if vertices could still be
supported when Fill Style is kQ3FillStylePoints.

Roger.




On 2 Feb, 2007, at 00:02, James Walker wrote:

> TriMesh edges aren't used in Geom Test or in any of our test files.  I
> was wondering if anyone would care if I didn't implement edges in  
> my new
> renderer.
> -- 
>    James W. Walker, Innoventive Software LLC

Re: Anyone use edges in TriMeshes?

[Jose' C. <cru...@ce...>]

Il giorno 02/feb/07, alle ore 01:02, James Walker ha scritto:

> TriMesh edges aren't used in Geom Test or in any of our test files.  I
> was wondering if anyone would care if I didn't implement edges in  
> my new
> renderer.

I'm using Edges in my own renderer, es. to tell if two coplanar  
triangles are a quad
and the wire frame should use them too (and the cartoon one), and  
certain geometries (like the cube) should create them when  
decomposing to trimeshes, so I thing are a "good thing"

but

I can't see the point to USE them in a solid interactive renderer, so  
in my opinion you can leave them apart


Pax et Bonum

# dott. Jose' Cruanyes Aguilar  -  C.E. Soft srl
#  Pzza. Firenze,4 MILANO  -  XX Settembre 10, CREMONA
#   02,33603122                0372,460602

Re: Anyone use edges in TriMeshes?

[Kevin M. <mat...@ar...>]

Good question! - I think TriMesh edges are used in DesignWorkshop, which we're still hoping to convert to Quesa "real soon".

I'll have to check to be sure.

thanks,

Kevin


On Thu, 01 Feb 2007 16:02:40 -0800, James Walker wrote:
> TriMesh edges aren't used in Geom Test or in any of our test files.  I 
> was wondering if anyone would care if I didn't implement edges in my new 
> renderer.
> -- 
>    James W. Walker, Innoventive Software LLC
>    <http://www.frameforge3d.com/>
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your 
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quesa-develop mailing list
> Que...@li...
> https://lists.sourceforge.net/lists/listinfo/quesa-develop