Menu
▾
▴
quesa-develop
|
From: James W. <ja...@fr...> - 2007-02-09 02:37:46
|
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/>
|
|
From: Jose' C. <cru...@ce...> - 2007-02-09 17:17:34
|
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 |
|
From: James W. <ja...@fr...> - 2007-02-09 18:28:26
|
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/> |
|
From: Jose' C. <cru...@ce...> - 2007-02-09 18:52:22
|
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 |
|
From: James W. <ja...@fr...> - 2007-02-09 19:14:15
|
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/> |
|
From: James W. <ja...@fr...> - 2007-02-09 20:01:00
|
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/> |
|
From: Jose' C. <cru...@ce...> - 2007-02-09 20:10:34
|
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 |
|
From: James W. <ja...@fr...> - 2007-02-09 20:27:47
|
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/> |
|
From: Jose' C. <cru...@ce...> - 2007-02-09 20:46:34
|
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 |
|
From: James W. W. <os...@jw...> - 2007-02-10 23:49:12
|
On Feb 9, 2007, at 12:46 PM, Jose' Cruanyes wrote: > 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... > For the record, I have changed it so that it will use Q3TriMesh_Optimize if needed. |
