This was answered earlier, but I thought I'd elaborate some more. On Mar 1, 2014, at 5:02 PM, Csaba Nagy wrote:
> It seems that the sketch support in BRL-CAD is very buggy or perhaps not > fully implemented... I would like to get an informed opinion on the > status quo. Sketches themselves are predominantly complete so far as everything observed from a DXF import, but you are correct in that we define support for NURBS segments but do no implement (one can use Bezier curves instead). Worth noting that we don't really document them or present them in our sketch editing GUI either. That's the only known issue with sketch+extrudes, so I'd be interested in hearing what CARC issue you encountered. As for sketch+revolves, they indeed are rather limited as that's one of our newest primitives. > For the Extrude part, after a quick code check I concluded that support > for NURB segments is not coded at all, they are simply ignored... also > the CARC segments are buggy, some work some not. NURBS references might as well not be listed in there. They were stubbed in long ago as a nice-to-have and abandoned after someone discovered they didn't need them for the data they were importing. > The Revolve primitive - I could not get it work with anything else than > line segments. They indeed only work for line segments. This was GSoC work a few years ago. > Even with those I'm not sure what are the requirements > for the resulting shape to raytrace properly, for example it's not clear > what happens with points on the revolution axis. It seems that the first > and end points will be automatically closed with a disc even if they are > not on the axis. This is written somewhere, but basically if you don't define a closed curve, it implicitly closes to the axis of revolution. As a solid modeling system, we should never end up with surfaces floating in space. So if you have a sketch with a single vertical line segment in it, that's going to make a cylinder. The alternative is throw an error or implement some form of plate-mode where we assign a thickness. If you define a closed curve, it does what you'd expect. > Also some of the parameters are ignored, or at least it seems so, and > others I modified but the effects were not consistent... We're (intentionally?) not very good at 2D modeling methods, which sketches fall under. It's received minimal attention, mostly for representing geometry being imported. > Generally where can I find some documentation of how it works in > detail ? Such documentation, beyond the source code, does not exist for sketch entities. This is probably the most detail available: http://brlcad.org/wiki/Sketch > * 3D path (to allow curves in space); > > * extrusion along a path -> this would cover both extrusion (linear > path) and revolution (circular arc); This is on our To-Do but actually quite complicated for arbitrary primitives and especially for NURBS geometry ... it'd be really cool to be able to take any geometry, whether a 2D sketch or some 3D shape, and sweep it along a path. Gladly help anyone who want to take it on as a project, but it's not easy! > It seems that other CAD projects implemented/discussed this: > > http://wiki.blender.org/index.php/Doc:2.4/Tutorials/Modeling/Curves/Extrude_Along_Path > > http://www.we-r-here.com/cad/tutorials/level_3/3-7a.htm > > https://github.com/openscad/openscad/issues/114 Blender's not CAD so they get to work in polygonal mesh space where extrusions along a path are much easier. The second is a tutorial for AutoCAD which, like all the major CAD engines, implement extrusions along a path in a variety of ways but not in ways we can use or learn from them. OpenSCAD also predominantly works in polygonal mesh and/or a UV parametric space (tessellation/sampling), so they also aren't solving the harder CAD geometry problem. > So what is the status quo in this area ? Is there any existing effort > which is not already in the primitives code ? No effort. It's listed as the first primitives idea on my ideas page: http://brlcad.org/~sean/ideas.html It's just waiting for someone to be inspired. > Implementing some of this could be an interesting GSOC project too. I > would also like to have a stab at it but my attention is currently on > the python-brlcad project and time is limited... It's certainly possible for GSoC, but it would be extremely difficult. Doable, just not in a couple months time. Revolve is considerably "easier" mathematically, but it couldn't be completed by a very competent coder within GSoC's timeframe. Cheers! Sean ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
