 | | Rendering implementation details —Mark Tarrabain
|
| | | I was envisioning how an LDraw renderer would be implemented if it were done with OpenGL, and I've arrived at some questions that I can't answer for myself. I'm particularly wondering about line type #5, the optional line. According to the LDraw (...) (20 years ago, 24-Jan-05, to lugnet.cad.dev)
|
| | | |
| | | | | Re: Rendering implementation details —Orion Pobursky
|
| | | | | (...) Someone once suggested to me (Dan from Microsoft maybe?) that given today graphics libraries, one could probably get away with ignoring op-lines altogether and use edge detection. This would present a potential problem since edge color is (...) (20 years ago, 24-Jan-05, to lugnet.cad.dev)
|
| | | | | |
| | | | | Re: Rendering implementation details —Don Heyse
|
| | | | | (...) You're right about the performance hit. We've discussed this issue previously on lugnet, because quite a few of the renderers out there use opengl (ldview, leocad, ldglite, Mac Brick Cad...) Source code is available for all of these if you (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
|
| | | | | |
| | | | | | | Re: Rendering implementation details —Travis Cobbs
|
| | | | | | (...) I'm not 100% sure, but I believe most (if not all) of these outlining algorithms expect you to know the difference between the front faces and the back faces. It could be that they could be adopted for use when you don't have this information, (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | Re: Rendering implementation details —Travis Cobbs
|
| | | | (...) I'm not sure it's possible to implement for real without serious slowdowns. It might be possible to implement in a vertex program, but I haven't studied vertex programs, so I really don't know. (I'm pretty sure you can't throw out a vertex (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Rendering implementation details —Mark Tarrabain
|
| | | | Okay.... having had a day to think about it and a night to sleep on it, I think I've figured out something.... But it would only work if the optional lines were incident to edges of polygons that are part of the object being drawn. I'm not sure if (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
|
| | | | |
| | | | | | Re: Rendering implementation details —Don Heyse
|
| | | | | (...) I don't see it. Are you sure this works in the perspective projection? Because I can't quite figure out what the magic view vector is in that case. I think you'd need to calculate one view vector for each edge endpoint, which brings the number (...) (20 years ago, 25-Jan-05, to lugnet.cad.dev)
|
| | | | | |
| | | | | | | Re: Rendering implementation details —Mark Tarrabain
|
| | | | | | (...) Actually, one can bring the number of transformations down to 1 for the entire _object_. Interesting what can happen when an idea sits in the brain and percolates for a couple of days. A new idea I had was to just transform the camera position (...) (20 years ago, 29-Jan-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Rendering implementation details —Don Heyse
|
| | | | | | (...) Ok, I drew a better picture (2 planes in space and a floating eye) and I'm starting to see. Maybe you're onto something. It takes 2 surface normals and one point on the edgeline to divide space into 4 quadrants. Then you only need to figure (...) (20 years ago, 29-Jan-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: Rendering implementation details —Mark Tarrabain
|
| | | | | | | (...) It doesn't matter, actually. In one way or another, optional lines are required. In general, the "magic halo" effect only highlights _outside_ edges, but for a non-convex object, that won't necessarily be adqeuate. You can't even get away with (...) (20 years ago, 30-Jan-05, to lugnet.cad.dev)
|
| | | | | | | |
| | | | | | | | | Re: Rendering implementation details —Orion Pobursky
|
| | | | | | | | (...) It has been done before. Ildefonso Junior Zanette wrote a program called Windz, I use it all the time when I author parts. I can't remember if he publically released it. -Orion (20 years ago, 30-Jan-05, to lugnet.cad.dev)
|
| | | | | | | | |
| | | | | | | | | | Re: Rendering implementation details —Willy Tschager
|
| | | | | | | | (...) no, he didn't. when I last met him at legoworld 03 he promised to do it but actually never did (as far as I remember at the time windz had an error quote of 2-3 percent - too much from his point of view :-(( w. actually I'll add the (...) (20 years ago, 31-Jan-05, to lugnet.cad.dev)
|
| | | | | | | | |
| | | | | | | | BFCFixer —Mark Tarrabain
|
| | | | | | (...) Well, I had some spare time today... so I wrote one. It goes through a single LDraw part file and reorients all the polygons in it to have the same winding. It comprehends the notion of subfiles and already BFC compliant parts, and puts the (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: BFCFixer —Chris Dee
|
| | | | | | | (...) I may be being dense here, but I dont understand how this can be done programatically. The point of BFC is to allow renderers to understand if a particular polygon is facing the camera or facing away from it. If all polygons are wound (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | | |
| | | | | | | | | Re: BFCFixer —Ross Crawford
|
| | | | | | | | | (...) I think it can be done for simple objects, by choosing a random winding for 1 polygon, then processing all touching polygons so they're wound the same way (when looking from the same side - out ot in). This would produce a result that is (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | | | | |
| | | | | | | | | | | Re: BFCFixer —Chris Dee
|
| | | | | | | | | | (...) Of course, it's that simple - thanks. Except some of the most basic LDraw parts (regular bricks) fail this test because the studs are "stuck on" a complete quad, rather than a surface peppered with stud-sized holes. Chris (20 years ago, 4-Feb-05, to lugnet.cad.dev)
|
| | | | | | | | | | |
| | | | | | | | | | | | Re: BFCFixer —Mark Tarrabain
|
| | | | | | | | | | (...) Such components are handled correctly by BFCFixer as "detached" submodels, and are oriented consistently with the rest of the polygons in the file as long as each independant submodel is sufficiently enclosed that a correct winding can be (...) (20 years ago, 5-Feb-05, to lugnet.cad.dev)
|
| | | | | | | | | | |
| | | | | | | | | Re: BFCFixer —Steve Bliss
|
| | | | | | | | (...) The way it's been done before is to draw rays from the origin outward. The first polygon a ray crosses is facing inward, and the last polygon a ray crosses would be facing outward. The ones in between *should* alternate facing in and out. Do (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | | | |
| | | | | | | | Re: BFCFixer —Steve Bliss
|
| | | | | | (...) Oh yeah! Let me at it. :) Steve (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: BFCFixer —Mark Tarrabain
|
| | | | | | (...) Ask, and ye shall receive. (URL) code is included (hopefully my crude hackings can be deciphered by others) as well as an executable jarfile in the dist/ subdirectory. Enjoy. If you find any major bugs, let me know, and I'll see what I can do, (...) (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | | | Re: BFCFixer —Dan Boger
|
| | | | | | (...) Would you guys want a code repository for this? I have a SVN repo set up that I could easily add this as a project... Just LMK! (20 years ago, 3-Feb-05, to lugnet.cad.dev)
|
| | | | | | |
| | | | | | Re: Rendering implementation details —Stefan Gustavson
|
| | | | (...) What you are describing is in fact a very old and basic edge rendering algorithm, which can be found in most detailed textbooks on computer graphics. CAD style and wire frame rendering went out of style during the 90's, so some recent "fancy (...) (20 years ago, 29-Jan-05, to lugnet.cad.dev)
|
| | | | |
