It’s not the editors (those are things like MLCAD, LeoCAD and Bricksmith) or the renderers (like LDView) but the system all of these use and the parts library. To quickly give an overview it’s a CAD system and associated library designed to let you build LEGO models on your computer. The first question is, obviously, have you ever heard of LDraw? And if you have do you know what it is? Have you ever considered using it but decided against it? If so why? Did you know the parts are all designed by volunteers? Oddly enough I feel I’ve seen a resurgence in LDraw work recently but of course like all of us I tend to see what I want to see so I figured I’d throw some questions out to a wider audience. Ok i think i got the main idea.A recent discussion at LUGNET raised questions about the future of LDraw in the fan community.
#BRICKSMITH SOURCEFORGE CODE#
For modifying your code to handle this case, I think there are two things you _must_ do:
Unfortunately i'm working in javascript and i don't think there's a sane way to include c code. The Bricksmith mesh smoother is a straight cross-platform pure C API, and it translates lines, tris and quads into indexed GL meshes - I think you could probably just use it under BrickSmith's open source license. It smoothed both, as long as they have conditional lines attached. Does your original code handle smoothing of rounded surfaces made of triangles too or only quads? The algorithm that I ended up using uses triangles, and thus decomposing the quads is not a problem. I've been meaning to write up a document based on the discussion - people covered fixing the loss of precision due to rotation matrices, detecting and repairing T junctions, etc. So I wanted to build a smoothing algorithm that would not require conditional lines since they were already unnecessary for the rest of BrickSmith. My thinking on this was: you can easily create a renderer that looks good without rendering conditional lines at all if you are doing 3-d shaded solid drawing. If you do not do this, the direction of the normal will be biased and you will get a smooth mesh, but a smooth mesh whose lighting appears to run at an angle along the split line of the quads.įinally, just a quick note: the BrickSmith code matches LDView in that it smoothes any edge that is not sharp and does not have a line - it does not require conditional lines to induce smoothing. When you find all incident triangles, you must weight the averaging of the normals by the _angle_ of the triangle at vertex V. You must be prepared to smooth a vertex by an _arbitrary_ number of incident triangles - in other words, think of all triangles touching vertex V as a fan - every one of them may contribute to smoothing, and there can easily be more than 4 - there will be 6 in the case of quads (because of the necessary split) or more for other LDraw shapes. The Bricksmith mesh smoother is a straight cross-platform pure C API, and it translates lines, tris and quads into indexed GL meshes - I think you could probably just use it under BrickSmith's open source license.ģ. Does your original code handle smoothing of rounded surfaces made of triangles too or only quads? The algorithm that I ended up using uses triangles, and thus decomposing the quads is not a problem.Ģ. I ended up implementing smoothing in BrickSmith based on the discussion. There was a lengthy discussion of smoothing a while ago on the forums: You can see it here:ĭo you have any idea on how i could correct this issue? I tried to keep track of triangle pairs forming quads, but i couldn't manage to restore a working solution.Įventually i could move all smoothing code to BEFORE generating the 3d mesh, that is while still working with plain ldraw objects (quads and tri), but it looks like an huge amount of work. But now it happends that if i have two quad connected by a condline, only two of the four triangles are affected, the other two staying unsmoothed, effectively creating a zigzag pattern. I've adjusted for the Face4 removal in the simplest way: by adding two Face3 composing the quad. Smoothing means averaging all normals (per-vertex face normals) at each end of the conditional lines. So my algorithm worked like this: if two faces have a conditional line on the common edge, that means the faces should be smoothed. I relied to quads for my smoothing algorithm, and everything broke Now the whole library only deals with triangles (Face3). I've found a bitter suprise: they deprecated the Quad primitive (Face4). I'm upgrading my webgl renderer program Brigl to work with the latest version of Three.js (the 3d engine i use).
0 kommentar(er)
