On Wed, May 23, 2012 at 11:29 AM, phoenix <[email protected]> wrote:
>> For me it looks like rt_revolve_brep() creates full revolutions only.
>> This would be a bug there.
Agreed.
There has been some consideration given to the possibility of having
revolve simply be a wrapper around the relevant BREP logic - in
essence, the "implicit" parameters would just be used to generate a
corresponding BREP under the hood. The major trick is to determine if
a supplied sketch is "closed" (and if not, finding a "subsketch" that
is closed, if it exists) - I don't know that we solve that problem
very well yet. Going that route, the way forward would be to get
revolve working in BREP form assuming a well behaved sketch, and build
up robustness wise from there.
Sean, what's your opinion?
It's my understanding that openNURBS concept of a revolved sketch is not the same as ours (nor other solid modeling systems for that matter), so one could spend a long time down that rabbit hole only to find out that we still have to stitch together or convert some revolves by hand anyways because openNURBS doesn't support that type.
Moreover, I'd bet our current implicit method of raytracing revolves will be considerably faster than something using a surface boundary representation under the hood. If you can get them to match as closely as you can, just document the current status (as comments in that file) if they can't be made to fully sync this week. Perhaps add a bullet into the TODO file.
Peripherally, I would suggest not spending more than three days on any single primitive before documenting and moving on. There are approximately 26 primitives to get through. :)
Cheers!
Sean
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
