Answer on possible fix for trimmed nurbs in display list
ruediger janecke <ruediger.janecke <at> cadvice.de>
2008-05-02 15:54:35 GMT
Dear Brian, dear mesa3d-team,
concerning the global variable "triangle_status" it can/ should be
made local into module "execute_list".
What am I trying to do:
I'm trying to interprete the opcode sequences
| EXT_0 | EVAL_C2 | EVAL_C2 | ... | EVAL_C2 | END |,
which are currently not interpreted - hence the missing triangles
along the trimcurves as my accompanying pics show.
As soon as an EXT_0-opcode is encoutered, I prepare to gather for
following EVAL_C2-opcodes (which each contains one pair of u and v):
"triangle_status" is set to 1.
As soon as three EVAL_C2-opcodes have been arrived
("triangle_status" is then 4 (four)), a triangle through
Begin, EvalCoord2f, EvalCoord2f, EvalCoord2f, End is generated.
Some of those above mentioned opcodes sequences are not just a
triple of EVAL_C2's, but rather contain more than three EVAL_C2's:
they represent a triangle fan.
Hence, there is code to generate triangles at "case OPCODE_END:"
and at "case OPCODE_EVAL_C2:".
Derive triangles from a triangle fan sequence, the first point
(the "pivot" of the fan) has to be used for all triangles being
made from that fan.
The setting of "ctx->Driver.CurrentExecPrimitive = GL_POLYGON+1;"
was necessary to "allow" the
"Begin, EvalCoord2f, EvalCoord2f, EvalCoord2f, End" sequence.
Also, I was not able to generate triangle fans (was "rejected").
Now, looking at my code again, the
"ctx->Driver.CurrentExecPrimitive = PRIM_OUTSIDE_BEGIN_END;"
may be superfluous. I will try it.
Some provisions have been made to:
- "Recover" from a situation where a (yet) unknown opcode or opcode
sequence may appear - especially within the opcode sequence I'm
trying to interprete.
It may be very well, that with working more with display lists,
other kind of opcode sequences not yet interpreted may be
- Still execute the "regular" END-opcodes and EVAL_C2-opcodes,
when there is no such opcode sequence representing triangles.
My possible suggested fix may not be the final solution and one may
encounter further demands with the display list, but it is - especially
to me - a further step using the OpenGL lib with trimmed b-splines in
the display list and gain more experience.
Regarding the test case using so much memory and being display quite
slow, I will try to make it simpler/ smaller.
On the other hand, the surface (half sphere) is just five times five
controlpoints and the trimcurve "across" the sphere has that many
points (pwl-curve), to do the trimming accurate enough.
OK, if it is that curve, that makes the example looking that large,
I will decrement the curve to a line, that will then trim the half
sphere to a quarter sphere.
You will receive the reduced example within the next days.
Also, I suspect the reason of the slow execution being the surface a
form of a sphere, I will try to make it rather flat and see what
Also, it may be worth to reduce the geometric size and/ or the
parameterization of the surface.
If there are any further questions or comments, pls. let me know.
Brian Paul wrote 2008-05-02 02:10 AM:
> ruediger janecke wrote 05/01/2008 09:41 PM:
>> Dear mesa3d-team,
>> I'am resending the mail with the file in not-zip-format again -
>> reason: mail was rejected again by your server, claiming for
>> still being zip-files in my mail.
>> Now I put attachments into a tar-file - all unzipped.
>> Herewith I forward the suggested fix for the example "trim.c with
>> display list".
>> I also included another test example
>> which is a half sphere in nurbs form being trimmed, displayed by the
>> list and also missing triangles along the trimcurve.
>> My suggested possible fix is in "dlist.c"
> Hmm, this doesn't look like a very clean fix. Global vars are a bad
> sign. Can you explain what exactly your patch is trying to do?
>> I also noticed, "nurbs_half_sphere_trimmed_w_dlist.c" being quite slow.
>> There is a lot of paging going on.
>> I will try to identify the reason.
> Yeah, the test is using over 600MB of memory (with NVIDIA's driver too).
> Could you come up with a smaller/simpler test case?
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.