Hi TC,
:-) I too would stick with CSG at this point, not knowing the cost for the CSG
object as isosurface approach. 100K primitives - wow.

The complexity / difficulty however would not be in the modeling - that would be
much simpler than what Mr Lipka has already done. If the train is a complete
'object' in the POVRay sense, you stick the train into the ObjectAsIso()
function and you have a very complex, single isosurface (1).

The hard part is getting the beveling into the code treating the train
as an isosurface. And, the hard part there is not coming up with ways to bevel -
existing interpolation techniques would work - it is doing that beveling in an
amount of compute resource any of us would tolerate.

I consider my hacked C++ compiled ObjectAsIso() implementation 'just barely'
tolerable for compute resource on today's most current multi-core processors. I
personally do not see a way to a beveling implementation that is not quite a bit
more expensive, but, who knows.

Bill
---------

(1) - Stretching a bit currently because all the csg behind the isosurface
'treatment' of the train is seen as one object by POVRay's existing search
mechanisms. The render time of this 'object-as-iso' approach goes up
dramatically as the CSG count in the object goes up. This single train object
would need to be broken into smaller object-as-isosurface objects to be a
practical render --> but, this piece-wise, build it up approach is how we do big
CSG objects today. Also practically we are unlikely to want the same beveling
magnitude across every shape of the whole train. The beveling would
likely be tuned for each object.

"TC" <do-not-reply@i-do get-enough-spam-already-2498.com> wrote:
> Do you have any idea how to approach the complex modeling required for your
> kind of beveled surfaces using isosurfaces? Does anybody in this newsgroup?

Post a reply to this message