 | | | | | | |
| |
|
Bricksmith 2.4 adds the following
features:
- Drawing speed improvements of up to 1200%
- 64-bit native on Mac OS X 10.6
- Viewports fill their entire frame
- Supports displaying the newly-standardized direct RGB color syntax
- Supports displaying legacy blended colors from the original LDRAW
- Saved files are formatted in traditional LDraw text style instead of fixed-width columns
It also fixes the following bugs:
- Fixed part selection failures for certain indirectly-referenced objects
- Eliminated several extra redraws
You read that right: Bricksmith 2.4 is over ten times faster than Bricksmith 2.3
on a computer with a good graphics card. (Even with a woefully underpowered
graphics card, you’ll still see a huge improvement.) Bricksmith 2.4 actually
achieves a faster framerate than LDView on my computer. Now you can enjoy
real-time interaction with models containing thousands of pieces!
Bricksmith requires Mac OS X 10.5 or later, and may be download it at
http://bricksmith.sourceforge.net/. It is both Intel and PowerPC native.
Sincerely,
Allen Smith
| | | | | | | | | | | | | | | |
In lugnet.announce, Allen Smith wrote:
| |
Bricksmith 2.4 adds the following
features:
- Drawing speed improvements of up to 1200%
- 64-bit native on Mac OS X 10.6
- Viewports fill their entire frame
- Supports displaying the newly-standardized direct RGB color syntax
- Supports displaying legacy blended colors from the original LDRAW
- Saved files are formatted in traditional LDraw text style instead of fixed-width columns
|
...snip....
Allan,
Congratulations on such a great improvement! Keep up the good work.
Kevin
| | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Kevin L. Clague wrote:
snip
| |
| |
- Drawing speed improvements of up to 1200% • snip
|
Kevin
|
Hi, Keving
Just from a technical interest, how did you achieve that boost?
I’m in the midst of writing a new LDraw renderer myself, so I’m very interested
in any possible improvements I can implement over the old LD4DStudio rendering
method. Although I suspect it has to do with alpha blending and or conditional
line rendering (none of whom are done in LD4D, but I would like to do in the new
implementation).
Anyhow it sounds great, maybe I get to use it one day (I’m planning to buy an
apple for some years now).
Roland
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Roland Melkert wrote:
| |
In lugnet.cad.dev.mac, Kevin L. Clague wrote:
snip
| |
| |
- Drawing speed improvements of up to 1200% snip
|
Kevin
|
Hi, Keving
Just from a technical interest, how did you achieve that boost?
I’m in the midst of writing a new LDraw renderer myself, so I’m very
interested in any possible improvements I can implement over the old
LD4DStudio rendering method. Although I suspect it has to do with alpha
blending and or conditional line rendering (none of whom are done in LD4D,
but I would like to do in the new implementation).
Anyhow it sounds great, maybe I get to use it one day (I’m planning to buy an
apple for some years now).
Roland
|
Hi Roland,
Just to be clear, Allan recoded and achieved this fantastic performance
improvement.
Kevin
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Kevin L. Clague wrote:
snip
| |
Hi Roland,
Just to be clear, Allan recoded and achieved this fantastic performance
improvement.
Kevin
|
Hi Kevin,
Sorry I replied to the wrong message, that’s what you get if you read the group
in a newsgroup client and post at the site.
Still hoping Allan could share some insight on the rendering technique(s) used.
Roland
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Roland Melkert wrote:
| |
In lugnet.cad.dev.mac, Kevin L. Clague wrote:
snip
| |
| |
- Drawing speed improvements of up to 1200% snip
|
|
Just from a technical interest, how did you achieve that boost?
I’m in the midst of writing a new LDraw renderer myself, so I’m very
interested in any possible improvements I can implement over the old
LD4DStudio rendering method. Although I suspect it has to do with alpha
blending and or conditional line rendering (none of whom are done in LD4D,
but I would like to do in the new implementation).
Anyhow it sounds great, maybe I get to use it one day (I’m planning to buy an
apple for some years now).
Roland
|
Hi Roland,
Bricksmith now recursively flattens the geometry for each referenced top-level
part then sorts it according to primitive type (triangles, quads, lines). Since
the primitives are sorted, each type can be enclosed in a single glBegin while
display lists are compiled. I create a unique display list for each color
variation of the part. Flattening and sorting the primitives allowed the display
lists to perform vastly improved internal optimizations over what they were able
to do with the unsorted data from the previous version of Bricksmith.
Unfortunately, all this is a bit beside the point because display lists are on
their way out, deprecated, not even available on the iPhone, etc. You are
supposed to be using VBOs and VAOs nowadays. Unfortunately I am not a 3D guru,
wrote my program using obsolete methods to begin with, and it has taken me a
while to plan a transition.
By the way, Bricksmith does not render conditional lines. I consider shading to
be a sufficient substitute, and conditional lines sound difficult to optimize.
Allen
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
By the way, Bricksmith does not render conditional lines. I consider shading
to be a sufficient substitute, and conditional lines sound difficult to
optimize.
|
Heh, you hit that problem too? I’ve played around writing an OpenGL LDraw
renderer based exclusively on display lists, but I can’t for the life of me
figure out how to handle conditional lines in this setup. Has anyone else
solved this peculiarly specific problem?
Remi
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Remi Gagne wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
By the way, Bricksmith does not render conditional lines. I consider shading
to be a sufficient substitute, and conditional lines sound difficult to
optimize.
|
Heh, you hit that problem too? I’ve played around writing an OpenGL LDraw
renderer based exclusively on display lists, but I can’t for the life of me
figure out how to handle conditional lines in this setup. Has anyone else
solved this peculiarly specific problem?
|
You can ignore the conditional lines and achieve the same effect with
display lists using the stencil buffer techniques presented here:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node108.html
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Remi Gagne wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
By the way, Bricksmith does not render conditional lines. I consider
shading to be a sufficient substitute, and conditional lines sound
difficult to optimize.
|
Heh, you hit that problem too? I’ve played around writing an OpenGL LDraw
renderer based exclusively on display lists, but I can’t for the life of me
figure out how to handle conditional lines in this setup. Has anyone else
solved this peculiarly specific problem?
|
You can ignore the conditional lines and achieve the same effect with
display lists using the stencil buffer techniques presented here:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node108.html
|
And here’s a silhouette technique using BFC:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.8503&rep=rep1&type=pdf
This technique and the conditional lines both target the same edges lines
where the front facing polygons meet the back facing polygons, so the
results should be quite similar.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Remi Gagne wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
By the way, Bricksmith does not render conditional lines. I consider
shading to be a sufficient substitute, and conditional lines sound
difficult to optimize.
|
Heh, you hit that problem too? I’ve played around writing an OpenGL LDraw
renderer based exclusively on display lists, but I can’t for the life of me
figure out how to handle conditional lines in this setup. Has anyone else
solved this peculiarly specific problem?
|
You can ignore the conditional lines and achieve the same effect with
display lists using the stencil buffer techniques presented here:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node108.html
|
And here’s a silhouette technique using BFC:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.8503&rep=rep1&type=pdf
This technique and the conditional lines both target the same edges lines
where the front facing polygons meet the back facing polygons, so the
results should be quite similar.
|
And another thing...
The BFC technique actually has an advantage over conditional lines
because it works on the entire scene after it’s been assembled. Whereas
the conditional lines at the edges of the primitives are created in
advance, and must predict what they’re going to butt up against when the
entire scene has been assembled. This prediction may not always be
right, resulting in missing conditional lines and some visible where
they should not be.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Don Heyse wrote:
| |
In lugnet.cad.dev.mac, Remi Gagne wrote:
| |
In lugnet.cad.dev.mac, Allen Smith wrote:
| |
By the way, Bricksmith does not render conditional lines. I consider
shading to be a sufficient substitute, and conditional lines sound
difficult to optimize.
|
Heh, you hit that problem too? I’ve played around writing an OpenGL LDraw
renderer based exclusively on display lists, but I can’t for the life of
me figure out how to handle conditional lines in this setup. Has anyone
else solved this peculiarly specific problem?
|
You can ignore the conditional lines and achieve the same effect with
display lists using the stencil buffer techniques presented here:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node108.html
|
And here’s a silhouette technique using BFC:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.8503&rep=rep1&type=pdf
This technique and the conditional lines both target the same edges lines
where the front facing polygons meet the back facing polygons, so the
results should be quite similar.
|
And another thing...
The BFC technique actually has an advantage over conditional lines
because it works on the entire scene after it’s been assembled. Whereas
the conditional lines at the edges of the primitives are created in
advance, and must predict what they’re going to butt up against when the
entire scene has been assembled. This prediction may not always be
right, resulting in missing conditional lines and some visible where
they should not be.
|
So finally this brings us to a technique that combines the predictive
abilities of the conditional lines with the runtime advantages of the
stencil and BFC algorithms.
Think of the conditional line as a pair of triangles with a shared edge
line. You can ensure the two triangles are wound the same way by going
through the shared edge line in the opposite direction in the two
triangles. This means if we try to draw both triangles in a scene where
the conditional line should show then one of the triangles can be culled
by BFC. So we take advantage of this by drawing the conditional line
triangles (edges only) into the stencil buffer. Then we redraw only
the conditional lines and use the stencil buffer to pass only the
conditional lines that were drawn once. Conditional lines that were
drawn 0 times, or more than 1 time do not pass.
I think it could work. What do you think?
Enjoy,
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Don Heyse wrote:
| |
So finally this brings us to a technique that combines the predictive
abilities of the conditional lines with the runtime advantages of the
stencil and BFC algorithms.
Think of the conditional line as a pair of triangles with a shared edge
line. You can ensure the two triangles are wound the same way by going
through the shared edge line in the opposite direction in the two
triangles. This means if we try to draw both triangles in a scene where
the conditional line should show then one of the triangles can be culled
by BFC. So we take advantage of this by drawing the conditional line
triangles (edges only) into the stencil buffer. Then we redraw only
the conditional lines and use the stencil buffer to pass only the
conditional lines that were drawn once. Conditional lines that were
drawn 0 times, or more than 1 time do not pass.
I think it could work. What do you think?
Enjoy,
Don
|
Interesting, but complicated IMO :-)
Shaders offer a much easier implementation, and (I suspect) a faster one.
Geometry-shaders for preference, but the algorithm can be implemented using
vertex-shaders or even ARB vertex-programs to support older cards.
Alex
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Alex Taylor wrote:
| |
In lugnet.cad.dev, Don Heyse wrote:
| |
So finally this brings us to a technique that combines the predictive
abilities of the conditional lines with the runtime advantages of the
stencil and BFC algorithms.
Think of the conditional line as a pair of triangles with a shared edge
line. You can ensure the two triangles are wound the same way by going
through the shared edge line in the opposite direction in the two
triangles. This means if we try to draw both triangles in a scene where
the conditional line should show then one of the triangles can be culled
by BFC. So we take advantage of this by drawing the conditional line
triangles (edges only) into the stencil buffer. Then we redraw only
the conditional lines and use the stencil buffer to pass only the
conditional lines that were drawn once. Conditional lines that were
drawn 0 times, or more than 1 time do not pass.
I think it could work. What do you think?
|
Interesting, but complicated IMO :-)
Shaders offer a much easier implementation, and (I suspect) a faster one.
Geometry-shaders for preference, but the algorithm can be implemented using
vertex-shaders or even ARB vertex-programs to support older cards.
|
Ah ha! Yet another reason to read that vertex-shader book. So, are you
suggesting running this algorithm on the graphics card (with counters for
the vertices instead counting pixels in the stencil buffer) or perhaps
some other algorithm?
Anyhow, I think the one thing I wanted to point out here is that the
conditional lines contain more information than you might think. They’ve
got enough winding information to draw the silhouette using a BFC technique,
even if the part itself is not BFC compliant. If that can be implemented faster
using a vertex-shader on the graphics card, even better!
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Don Heyse wrote:
> Ah ha! Yet another reason to read that vertex-shader book. So, are you
> suggesting running this algorithm on the graphics card (with counters for
> the vertices instead counting pixels in the stencil buffer) or perhaps
> some other algorithm?
Actually, it's even simpler! This is the code for the geometry-shader:
#version 120
#extension GL_NV_geometry_shader4 : enable
varying out vec4 gl_TexCoord[];
float determinant(mat2 m)
{
return m[0][0] * m[1][1] - m[0][1] * m[1][0];
}
void main(void)
{
vec4 c1 = gl_PositionIn[0];
vec4 c2 = gl_PositionIn[3];
vec4 v1 = gl_PositionIn[1];
vec4 v2 = gl_PositionIn[2];
c1 /= c1.w;
c2 /= c2.w;
v1 /= v1.w;
v2 /= v2.w;
c1 -= v1;
c2 -= v1;
v2 -= v1;
if (sign(determinant(mat2(v2.x, v2.y, c1.x, c1.y))) ==
sign(determinant(mat2(v2.x, v2.y, c2.x, c2.y))))
{
gl_Position = gl_PositionIn[1];
EmitVertex();
gl_Position = gl_PositionIn[2];
EmitVertex();
EndPrimitive();
}
}
gl_Position[0] and gl_Position[3] are the control-points, [1] and [2] are the
vertices of the line. Using it is simply a matter of configuring the
shader-program to accept GL_LINES_ADJACENCY as input and return GL_LINES as
output, and then you do this to draw the line:
glUseProgram(myProgram);
glBegin(GL_LINES_ADJACENCY);
glVertex(control1);
glVertex(vertex1);
glVertex(vertex2);
glVertex(control2);
glEnd();
glUseProgram(0);
Obviously you can stick as many sets of controls/vertices in there as you like -
the shader will be called once for each set.
Performance is excellent :-) The above has one small drawback, though: geometry
shaders require one of the extensions "EXT_geometry_shader4",
"ARB_geometry_shader4" or "NV_geometry_shader4". This pretty much means you
need a fairly recent card - OpenGL3.2 or better. Fortunately, this is not the
only way to do the trick :-)
After a bit of head-scratching, I worked out how to pull off the same stunt with
a vertex-shader. It's slightly less efficient, since it isn't possible to pass
more than one vertex at a time to the shader (unlike the geometry-shader, which
can take multiple inputs) and so the calculation ends up having to be done twice
- once for each end of the line.
The control-points - along with both vertices - have to be passed to the shader
via some of the ancillary vertex-attributes, and since it also isn't possible
for a vertex-shader to /not/ emit a vertex when it leaves, if the algorithm
decides that the vertex should not be drawn it simply moves it to the origin.
OpenGL is smart enough not to draw a dot when both ends of the line are at the
same location :-)
I won't post the code for this one here, as it's misbehaving on one of my test
machines and I haven't had time to debug it. I'm pretty sure it's a driver bug,
but still :-(
Vertex-shaders require OpenGL 2 or better, so we have a third approach :-) It
is in fact possible to do this with the ancient ARB vertex-program, which is
available from IIRC OpenGL 1.2 and up. It's basically the same algorithm,
complicated ever so slightly by the facts that a) vertex-programs are in
assembler, and b) the language has no flow-control instructions...
As before, you pass the vertices and control-points in via four spare
vertex-attribs (11, 12, 13 and 14 in the code below) and the program is executed
for each input vertex.
!!ARBvp1.0
TEMP c1;
TEMP c2;
TEMP v1;
TEMP v2;
TEMP c1w;
TEMP c2w;
TEMP v1w;
TEMP v2w;
TEMP det1;
TEMP det2;
TEMP floor;
TEMP sign;
TEMP factor;
DP4 c1.x, state.matrix.mvp.row[0], vertex.attrib[11];
DP4 c1.y, state.matrix.mvp.row[1], vertex.attrib[11];
DP4 c1.w, state.matrix.mvp.row[3], vertex.attrib[11];
RCP c1w, c1.w;
MUL c1, c1, c1w;
DP4 c2.x, state.matrix.mvp.row[0], vertex.attrib[12];
DP4 c2.y, state.matrix.mvp.row[1], vertex.attrib[12];
DP4 c2.w, state.matrix.mvp.row[3], vertex.attrib[12];
RCP c2w, c2.w;
MUL c2, c2, c2w;
DP4 v1.x, state.matrix.mvp.row[0], vertex.attrib[13];
DP4 v1.y, state.matrix.mvp.row[1], vertex.attrib[13];
DP4 v1.w, state.matrix.mvp.row[3], vertex.attrib[13];
RCP v1w, v1.w;
MUL v1, v1, v1w;
DP4 v2.x, state.matrix.mvp.row[0], vertex.attrib[14];
DP4 v2.y, state.matrix.mvp.row[1], vertex.attrib[14];
DP4 v2.w, state.matrix.mvp.row[3], vertex.attrib[14];
RCP v2w, v2.w;
MUL v2, v2, v2w;
SUB c2, c2, v1;
SUB c1, c1, v1;
SUB v2, v2, v1;
XPD det1, v2, c1;
XPD det2, v2, c2;
MUL sign, det1.z, det2.z;
SGE factor, sign, 0.0;
TEMP vertexClip;
DP4 vertexClip.x, state.matrix.mvp.row[0], vertex.position;
DP4 vertexClip.y, state.matrix.mvp.row[1], vertex.position;
DP4 vertexClip.z, state.matrix.mvp.row[2], vertex.position;
DP4 vertexClip.w, state.matrix.mvp.row[3], vertex.position;
MUL result.position, vertexClip, factor;
END
This requires the "ARB_vertex_program" extension. Usage here is:
glEnable(GL_VERTEX_PROGRAM_ARB);
glBegin(GL_LINES);
glVertexAttrib(11, control1);
glVertexAttrib(12, control2);
glVertexAttrib(13, vertex1);
glVertexAttrib(14, vertex2);
glVertex(vertex1);
glVertex(vertex2);
glEnd();
glDisable(GL_VERTEX_PROGRAM_ARB);
(Note that in both cases in the interests of clarity I've deliberately omitted
the code which passes through things like normals, colours and texcoords.)
If anyone wants to use either of the above bits of code, please feel free :-)
And if you have questions, I'll be happy to answer them either here or via
email.
Alex
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Alex Taylor wrote:
> Actually, it's even simpler! This is the code for the geometry-shader:
...
Wow, that is simple. It looks just like the description of the algorithm
in the LDRAW specs.
I haven't felt this old since manipulating the colormap for animation went
outta style. :^)
Thanks for sharing,
Don
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Don Heyse wrote:
> I haven't felt this old since manipulating the colormap for animation went
> outta style. :^)
Hoo...that takes me back! :-) Doing the second shader was a bit of a blast from
the past, actually - it's over 10 years since I last wrote assembler in anger!
Alex
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Alex Taylor wrote:
> In lugnet.cad.dev, Don Heyse wrote:
> > Ah ha! Yet another reason to read that vertex-shader book. So, are you
> > suggesting running this algorithm on the graphics card (with counters for
> > the vertices instead counting pixels in the stencil buffer) or perhaps
> > some other algorithm?
>
>
> Actually, it's even simpler! This is the code for the geometry-shader:
<snip>
>
> Alex
Wow, this is amazing. I had no idea you could do these kinds of things with
shaders. Like Don I too think it's time for me to get a good book/document on
using shaders in OpenGL.
Thanks for the revelation.
Roland
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Allen Smith wrote:
snip
| |
Bricksmith now recursively flattens the geometry for each referenced
top-level part then sorts it according to primitive type (triangles, quads,
lines). Since the primitives are sorted, each type can be enclosed in a
single glBegin while display lists are compiled. I create a unique display
list for each color variation of the part. Flattening and sorting the
primitives allowed the display lists to perform vastly improved internal
optimizations over what they were able to do with the unsorted data from the
previous version of Bricksmith.
Unfortunately, all this is a bit beside the point because display lists are
on their way out, deprecated, not even available on the iPhone, etc. You are
supposed to be using VBOs and VAOs nowadays. Unfortunately I am not a 3D
guru, wrote my program using obsolete methods to begin with, and it has taken
me a while to plan a transition.
By the way, Bricksmith does not render conditional lines. I consider shading
to be a sufficient substitute, and conditional lines sound difficult to
optimize.
Allen
|
Thanks for the insight Allen,
I’m also not a 3D guru, but I like to fool around with it as much as anyone
interested in 3d programming.
Your method is roughly the same as what LD4DStdudio does, except I use VBO to
stuff whole high level parts in index-ed arrays. The indices are then grouped
per color (16 being also a color) so a minimum of glcolor’s are needed during
rendering. So it seems display lists aren’t ‘less’ then VBO at all to me.
Only problem with the highlevel part approach is you can’t support mirrored
submodels higher up in the rendering tree (like eg the star destroyed mpd uses)
cause it will mess up the normals. Or did you find a way around that?
Optimizations I was thinking of for my new renderer are using only triangles
instead of 1 on 1 ld quads and triangles cause quads will be split by the driver
anyway. (not sure if it’s actually faster doing it yourself but I’ll have to
test that.)
The conditional lines are indeed a pain, normal lines can go in vbo/display
lists much like the triangles but you have to test all conlines against the the
current projection matrix for every redraw. I was planning to do this
multithreaded (like LDView does).
Roland
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Roland Melkert wrote:
| |
Your method is roughly the same as what LD4DStdudio does, except I use VBO to
stuff whole high level parts in index-ed arrays. The indices are then grouped
per color (16 being also a color) so a minimum of glcolor’s are needed during
rendering. So it seems display lists aren’t ‘less’ then VBO at all to me.
|
One drawback with VBOs is that - unlike displaylists - you can’t stick arbitrary
GL calls in them. I’m using lists because I need to be able to put matrix
operations in them as well as geometry.
| |
Only problem with the highlevel part approach is you can’t support mirrored
submodels higher up in the rendering tree (like eg the star destroyed mpd
uses) cause it will mess up the normals. Or did you find a way around that?
|
Change the cull-face orientation ;-)
| |
Optimizations I was thinking of for my new renderer are using only triangles
instead of 1 on 1 ld quads and triangles cause quads will be split by the
driver anyway. (not sure if it’s actually faster doing it yourself but I’ll
have to test that.)
|
I can’t say I’ve noticed the difference myself, but I suspect it’ll depend on
the hardware and drivers as much as anything.
| |
The conditional lines are indeed a pain, normal lines can go in vbo/display
lists much like the triangles but you have to test all conlines against the
the current projection matrix for every redraw. I was planning to do this
multithreaded (like LDView does).
|
See my previous post :-) Offload the grunt-work to the graphics-card, and it
flies!
Alex
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.mac, Alex Taylor wrote:
snip
| |
| |
Only problem with the highlevel part approach is you can’t support mirrored
submodels higher up in the rendering tree (like eg the star destroyed mpd
uses) cause it will mess up the normals. Or did you find a way around that?
|
Change the cull-face orientation ;-)
|
snip
Duh, I was over thinking it big time. Thinking scaling etc would f-up the
normals, but with mirroring they will stay the same length. So you are right all
I have to do is check if it’s an ‘mirror’ matrix and then change the OpenGL
culling direction for all the subparts.
Thanks.
| | | | | | | | | | | | | | | | | |
In lugnet.announce, Allen Smith wrote:
| |
Bricksmith 2.4 adds the following
features:
- Drawing speed improvements of up to 1200%
- 64-bit native on Mac OS X 10.6
- Viewports fill their entire frame
- Supports displaying the newly-standardized direct RGB color syntax
- Supports displaying legacy blended colors from the original LDRAW
- Saved files are formatted in traditional LDraw text style instead of fixed-width columns
It also fixes the following bugs:
- Fixed part selection failures for certain indirectly-referenced objects
- Eliminated several extra redraws
You read that right: Bricksmith 2.4 is over ten times faster than Bricksmith
2.3 on a computer with a good graphics card. (Even with a woefully
underpowered graphics card, you’ll still see a huge improvement.) Bricksmith
2.4 actually achieves a faster framerate than LDView on my computer. Now you
can enjoy real-time interaction with models containing thousands of pieces!
Bricksmith requires Mac OS X 10.5 or later, and may be download it at
http://bricksmith.sourceforge.net/. It is both Intel and PowerPC native.
Sincerely,
Allen Smith
|
Great !!!!
One request can you make it posible to edit inserted minifigures with
minifig generator ?
Thanks
| | | | | | |
