| |
Hi folks,
over the latter half of the year 2009 I’ve been planning and experimenting on
the thought of a good CAD program for part authors. Now I’m unveiling my
thoughts to the public, but this is not an announcement. It’s too early for
such.
History
Over the course of summer I was having the thought in my mind and in early fall
I began to experiment on things like Togl (OpenGL frontend to Tcl/Tk) and code
related to inlining, compiling and rendering.
In late fall I though found myself with a
problem too hard for me to overcome and I overturned the thoughts. The program
turned out to act far too slow. Recently, however, I went through the code,
fixed some bugs and optimized it a tad by for example making the in-rotation
part be rendered lines-only, like in MLCAD.
More importantly, I figured that it’s possible.. as I knew exactly what I was
facing. The slowness, as it seems, is caused by either the inlining or compiling
code by duplicating compiled code. I created a “brick.dat” file, which was a
3002.dat inlined down to lowest level, and logged the compiled data of both
files. brick.dat was 46KB, while 3002.dat was 2.8MB! Now I’m looking into the
code and might as well fix the thing. :)
That’s why I’m posting this here. This is not an announcement, just sharing of
my plans and code.
Specs
LDForge, currently, is nothing more than a simple, bugged, renderer. But I’m
planning more:
Implemented features:
- Simple rendering with zoom, spin and offset
- BFC red/green view, albeit buggy
- Wireframe, edges-only and no-edges mode
- LDConfig.ldr support
- Transparency support (non-dithered due to OpenGL)
Planned features:
- The obvious: the basic things you need to author a part
- Functions for trimming lines
- Quick edgelining
- Polygon drawing (?)
- Complexity (=bowtie) detection and auto-fix (?)
- Multiple parts simultaneously open..? (Kind of against this because I fear it would cause LDForge to slow down)
- Integration of Philo’s tools (if he’s okay with it :D)
- Functions from MLCAD such as select by colour and type
- Primitive gallery
- More as I come up with them...
Bugs!
- Subpart inlining and compiling cause lots of duplicates, slowing the renderer tremendously
- Polygon sorting is bugged. I need help here - see below for details.
- BFC view is bugged.
- Conditional lines are not handled at all.
- Offset and spinning do not work the way I want them to. More minor issue, though..
- Most code is in forge.tcl and need to be sorted into separate files. Trivial, though.
LDConfig.ldr
LDConfig.ldr will be supported. However, speckle and glitter will quite probably
not be supported unless I’m supplied with the code to render them. They’re not
needed. ;)
LDConfig.ldr will probably be flouted in the manner of using coloured edgelines
ala alternate LDConfig and MLCAD 3.2. Naturally, as this will more than probably
be argued against, I’ll have this flouting in a configuration option.
Polygon sorting - help needed
I need a little bit help, however. The polygon sorting algorithm I have right
now does not work properly. Currently it’s done by calculating the center of the
polygon by simply calculating the means of the coordinates.
How do existing programs - LDView in particular as it’s an OpenGL one too - sort
polygons? I’d appreciate help tremendously here..
(Future) downloads
I have created a SourceForge project
for LDForge. I will be keeping an SVN repository in case people have interest in
this project with whatever interests they have. At this point, while I’m writing
this post, there’s nothing to get. I’ll flesh the project page out, just give me
time..
-Santeri
|
|
| |
In lugnet.cad, Santeri Piippo wrote:
| |
Hi folks, • - SNIP
Polygon sorting - help needed
I need a little bit help, however. The polygon sorting algorithm I have right
now does not work properly. Currently it’s done by calculating the center of
the polygon by simply calculating the means of the coordinates.
How do existing programs - LDView in particular as it’s an OpenGL one too -
sort polygons? I’d appreciate help tremendously here..
|
-SNIP-
At present I can not see the reason to sort polygons if you only want to display
them.
cu
mikeheide
|
|
| |
In lugnet.cad, Michael Heidemann wrote:
| |
In lugnet.cad, Santeri Piippo wrote:
| |
Hi folks, - SNIP
Polygon sorting - help needed
I need a little bit help, however. The polygon sorting algorithm I have
right now does not work properly. Currently it’s done by calculating the
center of the polygon by simply calculating the means of the coordinates.
How do existing programs - LDView in particular as it’s an OpenGL one too -
sort polygons? I’d appreciate help tremendously here..
|
-SNIP-
At present I can not see the reason to sort polygons if you only want to
display them.
cu
mikeheide
|
The polygons have to be painted on the screen in the correct order in order to
have the part displayed correctly. It’s not handled automatically. So I need an
algorithm to sort the polygons.. and my current one doesn’t work right.
-Santeri
|
|
| |
In lugnet.cad, Santeri Piippo wrote:
| |
Polygon sorting - help needed
I need a little bit help, however. The polygon sorting algorithm I have right
now does not work properly. Currently it’s done by calculating the center of
the polygon by simply calculating the means of the coordinates.
How do existing programs - LDView in particular as it’s an OpenGL one too -
sort polygons? I’d appreciate help tremendously here..
|
The only polygons that LDView sorts are transparent ones. Everything else is
handled by the OpenGL depth buffer (glEnable(GL_DEPTH_TEST), followed by
glDepthFunc(GL_LEQUAL)). Transparent polygons need to be sorted before being
drawn, and LDView does what you describe above for those. (There’s more to it
than that for transparent polygons; sorting is just one step.)
Sorting by the distance to the centroid is only an approximation, but it’s good
enough to look pretty good for transparent polygons. It’s not good enough to
be used as the primary means of hiding geometry that’s farther away from the
viewer.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
In lugnet.cad, Santeri Piippo wrote:
| |
Polygon sorting - help needed
I need a little bit help, however. The polygon sorting algorithm I have
right now does not work properly. Currently it’s done by calculating the
center of the polygon by simply calculating the means of the coordinates.
How do existing programs - LDView in particular as it’s an OpenGL one too -
sort polygons? I’d appreciate help tremendously here..
|
The only polygons that LDView sorts are transparent ones. Everything else is
handled by the OpenGL depth buffer (glEnable(GL_DEPTH_TEST), followed by
glDepthFunc(GL_LEQUAL)). Transparent polygons need to be sorted before
being drawn, and LDView does what you describe above for those. (There’s
more to it than that for transparent polygons; sorting is just one step.)
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther away
from the viewer.
|
If you prefer not to sort at all you can use glEnable(GL_POLYGON_STIPPLE)
for transparent polygons. It doesn’t look nearly as good, but it’s really
easy to code.
Have fun,
Don
|
|
| |
--snip--
| |
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther away
from the viewer.
--Travis
|
Out of interest which centroid do you use? I would have thought that the
bounding box center was better than the centre of all corner points (since these
cluster around areas of high detail) but you’ve presumably tried different
centroid algorithms.
Tim
|
|
| |
In lugnet.cad, Timothy Gould wrote:
| |
--snip--
| |
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther
away from the viewer.
--Travis
|
Out of interest which centroid do you use? I would have thought that the
bounding box center was better than the centre of all corner points (since
these cluster around areas of high detail) but you’ve presumably tried
different centroid algorithms.
|
For transparency, LDView sorts triangles, and only triangles, not parts. So the
centroid of each triangle is (p1 + p2 + p3) * (1/3).
All transparent geometry in the whole model goes into one big list of triangles.
While I’m at it, I calculate the centroid for each triangle so I only have to do
that at model load time. At the beginning of each frame, I calculate the
distance squared to each triangle’s centroid based on the current viewing angle.
Then I do a qsort() with those distances. (I used distance squared in order to
avoid an unnecessary square root.)
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
| |
The only polygons that LDView sorts are transparent ones. Everything else is
handled by the OpenGL depth buffer (glEnable(GL_DEPTH_TEST), followed by
glDepthFunc(GL_LEQUAL)). Transparent polygons need to be sorted before
being drawn, and LDView does what you describe above for those. (There’s
more to it than that for transparent polygons; sorting is just one step.)
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther away
from the viewer.
--Travis
|
I see.. but problem is that if I use glEnable(GL_DEPTH_TEST) then my polygons
won’t render at all. Tutorials related to OpenGL explicitly told not to use
GL_DEPTH_TEST because of this.. how did you avoid it?
|
|
| |
In lugnet.cad, Santeri Piippo wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
The only polygons that LDView sorts are transparent ones. Everything else
is handled by the OpenGL depth buffer (glEnable(GL_DEPTH_TEST), followed
by glDepthFunc(GL_LEQUAL)). Transparent polygons need to be sorted before
being drawn, and LDView does what you describe above for those. (There’s
more to it than that for transparent polygons; sorting is just one step.)
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther
away from the viewer.
--Travis
|
I see.. but problem is that if I use glEnable(GL_DEPTH_TEST) then my
polygons won’t render at all. Tutorials related to OpenGL explicitly told not
to use GL_DEPTH_TEST because of this.. how did you avoid it?
|
In order for GL_DEPTH_TEST to work, you have to clear the depth buffer at the
same time you clear the rest of the screen:
glClearDepth(1.0);
glClearColor(0.0, 0.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
|
|
(Note: the glClearDepth() and glClearColor() calls above aren’t really
necessary, since they pass the OpenGL default values, but just in case you used
some other value, the above is what you want for glClearDepth().)
--Travis
|
|
| |
> * Integration of <http://www.philohome.com/ldraw.htm Philo's tools> (if he's
> okay with it :D)
Perfectly OK! now I wonder what could be a correct user interface for that...
Philo
|
|
| |
In lugnet.cad.dev, Travis Cobbs wrote:
| |
In lugnet.cad, Santeri Piippo wrote:
| |
In lugnet.cad, Travis Cobbs wrote:
| |
The only polygons that LDView sorts are transparent ones. Everything else
is handled by the OpenGL depth buffer (glEnable(GL_DEPTH_TEST), followed
by glDepthFunc(GL_LEQUAL)). Transparent polygons need to be sorted before
being drawn, and LDView does what you describe above for those. (There’s
more to it than that for transparent polygons; sorting is just one step.)
Sorting by the distance to the centroid is only an approximation, but it’s
good enough to look pretty good for transparent polygons. It’s not good
enough to be used as the primary means of hiding geometry that’s farther
away from the viewer.
--Travis
|
I see.. but problem is that if I use glEnable(GL_DEPTH_TEST) then my
polygons won’t render at all. Tutorials related to OpenGL explicitly told
not to use GL_DEPTH_TEST because of this.. how did you avoid it?
|
In order for GL_DEPTH_TEST to work, you have to clear the depth buffer at
the same time you clear the rest of the screen:
glClearDepth(1.0);
glClearColor(0.0, 0.0, 0.0, 0.0);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
|
|
(Note: the glClearDepth() and glClearColor() calls above aren’t really
necessary, since they pass the OpenGL default values, but just in case you
used some other value, the above is what you want for glClearDepth().)
--Travis
|
Ah, thank you Travis! I got depth buffering working now. :)
No more problems with polygon sorting..
-Santeri
|
|
| |
In lugnet.cad, Don Heyse wrote:
| |
If you prefer not to sort at all you can use glEnable(GL_POLYGON_STIPPLE)
for transparent polygons. It doesn’t look nearly as good, but it’s really
easy to code.
Have fun,
Don
|
If you want a visual example on stipple, look at my LD4DStudio, it uses it for
transparent stuff.
In combination with depth buffer you don’t need to sort anything just push the
triangles and/or quad cords using glDrawElements and optionally ‘vbo’.
vbo means the driver will try to put all vertex data in video memory for
rendering, this is about four times faster on most cards.
I’ll try to (re)find the tutorials/website I used to get started with LD4DStudio
and post them tonight. But most stuff you can find by doing a search on
glDrawElements and vbo (vertex buffer object)
ps: i suggest moving this to dev
Roland
|
|
|
