Subject:
|
Some secrets of MLCad revealed ...
|
Newsgroups:
|
lugnet.cad.mlcad
|
Date:
|
Fri, 4 Jul 2003 20:11:03 GMT
|
Viewed:
|
3564 times
|
| |
|
|
Ok since a lot of you are asking me to provide more details about MLCad's
rendering technic I'll go and tell you some details about it:
During the development of MLCad I went through several stages trying to make
rendering faster, some of them with more and some with less success. Some
developers might/will have used this things as well but maybe the
combination does most.
The things where speed could benefit most where:
1) Part caching
MLCad keeps every single file loaded in an internal cache in memory so that
it doesn't need to search it and parse the contents everytime its requested
in a model.
2) Point reduction and Compression
Inside the cached file MLCad maintaines a list of objects representing
lines, triangles ... where each object stores all its points and parameters.
After a while I found it much more practicable to compress this drawing
information. Therefor MLCad can check the primitives after loading the file
for its points and creates a list of points used in this file.
If you check a file you will find a lot of equal points in there. Now each
point is stored only once, and therefor now calculated only once during
rendering. The primitive objects now refere to a point instead of carrying
it.
3) Image buffering
This once reduced drawing most but doesn't work for perspective display.
MLCad is using the scanline conversion and z-buffering methode for drawing.
Now imagine a stud drawn several thousend times and each time you calculate
the scan lines and depths of the single points.
Image buffering now is drawing the part into a virtual buffer first, and
then using this virtual buffer to actually draw the image. Now you do not
have to do all the calculations again, but can use precalculated information
instead. When drawing the buffer MLCad checks the actual depth of the stud
drawn and adds the z-buffer information for every single pixle to this
depth. The further processing is the same, if the pixel is in front of the
last pixel drawn, it will be drawn, otherwice not.
The image buffer itself is only reset if the orientation of part is changed.
This algorythm is used depending on the user setting even for complete
bricks. This means MLCad no longer has to calculate every single point,
line, triangle .. for the same part as long as it's orientation remains the
same.
The optimisation level in the rendering options controls these speedup
algorythms.
NONE doesn't use 2 and 3, low uses 2 only, medium uses 2, and 3 for files in
the p and s directory, and finaly high uses 2, and 3 for all parts.
I hope I could explain that understandable, if not just drop me note or ask
me....
Regards,
Michael
|
|
Message has 2 Replies:
 | | Re: Some secrets of MLCad revealed ...
|
| (...) I'm a bit behind on this thread, but thanks Michael. That explains a lot. I never thought of the image buffering approach for orthographic displays. It's a really neat idea! I do have a question though. How do you handle colors in the image (...) (21 years ago, 9-Jul-03, to lugnet.cad.mlcad)
|
12 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
