a couple of notes:
curves can't be a cloth or SBD object.
those dynamics systems are based on spring networks, and it's not
possible to estabilish a stable network on a serie of sequential points.
for that you already have the trick of using a one division grid and
extracting an edge for the curve.
it would be useful though to have a good wire op, the one in HDN is a
good example of something to steal right away without changing anything,
with pins and all.
many problems listed (like keeping a fixed length and some intersections
problems) are not as simple as they appear.
the human brain can grasp the most logical solution easily and visually,
but their solution isn't trivial (if sometimes possible at all).
if there was any work to do in those regards, it would again need to be
managed smartly, working on a single solid solution (like IK like
solutions for hair and wire dynamics) to use as a base for a number of
tools.
preserve length while modifying is exactly what is done on hair dynamics
if you look at it, and again isn't that simple.
it would however be nice to get something right away for the possible
ones like mesh to mesh, where all you need is a linear solution and a
subdivisions option, but I wouldn't say it's the highest priority, not
as high as solid shared solutions for other sets of problems.
projection based tools (they have a name by the way, usually
stencilling) would also be nice, but even nicer would be to get a decent
raycollider/raytracer in the SDK first, that way those things would
become trivial and fast to script or to bolt on.
this is a good example of what should be prioritized by "interpreting"
community requests instead of listening to them literally.
the point locator is a good step in the right direction, but exposing
XSI's internal voxelling (it has one already for sure) and some of its
already existing low level functions (which algorithmically are
unarguably some of the most efficient on the market) already in use in
tools like shrink wrap etc, would be even better.
It would also solve the backend needs, and cut on dev time, for an
infinite amount of problems that need solving in production in one
elegant swipe, and the community would then be able to provide the
user-friendly frontend while Soft refines or adds its own.
rendering curves (lack thereof) is something that has puzzled me for a
long time.
only max and HDN do it out of the box, yet it's a most fundamental
feature, and MRay has introduced their own curve primitive since a while
now.
I don't have a problem with that, as we use 3delight with our own
exporter here, and it supprots ricurves, but THAT should be a priority
that everybody could benefit from.
I'm off now, this is still partially on the right side of the fence, but
quickly going OT, and I don't want 'Stine to spank me with a metal ruler
(again)
******************************
| Raffaele Fragapane |
| Rising Sun Pictures |
| "Remember, TD is for TopDog" |
******************************
Tim Leydecker wrote:
> Features I would think useful as a modeling aid:
>
> -Intersect
> -Intersect based on viewing angle (e.g. like topview)
> -Create curve from intersecting meshes
> -Create curve from motionpaths, intersect, blend.
> -Draw curve on surface
> -Make curve a cloth object
> -Make curve a soft/rigidbody, sampling the knots
> or even oversampling between two knots based on
> a user set treshhold, e.g. adding knots to create better
> simulation results.
> -Keep fixed curvelength
>
> Features I would think useful for rendering:
>
> -render curve as (geometry)line, mapable/variable linewidth,
> displacement, parametrisation editable >>tons of cables,
> preview in viewport...
> -output curve as vectorline (*.eps) allowing to create masks,
> or any other compositingpath to attach effects to
> -render as toonline
>
> A few of the above are available in Maya, where
> Curves are often used to control dynamics, collision
> as guidehairs, paths, for modeling in general or whatnot.
> Rendering curves is a feature of 3DS Max, really handy.
>
> Cheers
>
> tim
>
>
> ----- Original Message ----- From: "kim aldis" <kim(at)aldis.org.uk>
> To: <XSI(at)Softimage.COM>
> Sent: Friday, July 14, 2006 8:39 AM
> Subject: RE: intersecting curves
>
>
>> My own experience with line intersections in 3Space, which bear some
>> relation to the curve intersection problem, is that there are no
>> really accurate, spot on solutions and that there are enough special
>> cases and fail situations to make them a pain in the arse to write
>> and they'll always be situations where they're going to fail and you
>> can spend more time beating your head against the fail situations
>> than you do writing the main thrust of the solution.
>>
>> The probably scenario, should such a function appear, is that it'll
>> work most of the time, fail a lot of the time and will need bucket
>> loads of support fielding the problems when they start flying in, as
>> they inevitably will.
>>
>> And yes, I'm sorry Mike but the comparison was smug and Halfy, who
>> spends a fair bit of time helping out here and who's responses are
>> with quality, deserved better.
>>
>>> -----Original Message-----
>>> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM] On
>>> Behalf Of Raffaele Fragapane
>>> Sent: 14 July 2006 07:06
>>> To: XSI(at)Softimage.COM
>>> Subject: Re: intersecting curves
>>>
>>> the issue here, is that that smug flash comparison simply doesn't hold.
>>> Halfy did answer at his best, which is a pretty good best in my
>>> opinion.
>>>
>>> I don't know what your math knowledge is like, but problems like
>>> closest point on surface, curves intersection etc., when in the set of
>>> high order descriptions like C2+ NURBS, are heavily math related.
>>> As good or bad, or dedicated, a developer can be, tools -ARE- limited
>>> by how problems can be solved at their lowest level, and advancing
>>> abstract math knowledge, or complex algorithm design for computational
>>> tasks, don't happen overnight.
>>>
>>> If we get into calculus 101 (we're talking age 14-15 education where I
>>> come from, don't know about other countries), you might remember the
>>> concept of integration and how annoying it was to solve all those
>>> problems by drawing lines all over a graph and then extrapolating a
>>> curve out of them.
>>>
>>> Problems like the one at hand are even worse, because they are even
>>> beyond normal integration and all the way into minimization (age 16-17
>>> for those that didn't drop out of high school), and minimization is,
>>> technically speaking, a bitch.
>>>
>>> The problem needs to be solved iteratively, which means figuring out
>>> the most convenient solution to discretize elements to compare (and
>>> such solutions, when they need to contemplate every possible case
>>> aren't necessarily trivial), and then running the comparison.
>>> Rinse and repeat until your comparison returns a result that meets a
>>> thresholding you could be happy with (which again isn't necessarily
>>> going to be obvious in every situation to an automated tool). This is a
>>> time consuming, uncertain, stability compromising and tricky process.
>>>
>>> Now, don't get me wrong, I'm not saying that just because it's an
>>> uncertain solution (you will always have, at best, a tolerable
>>> approximation) Soft shouldn't do anything about it; but considering
>>> that your knowledge of the problem at the base, or of software
>>> development, doesn't seem to be exactly in the same league of the
>>> problem we're discussing, your remarks were a bit smug.
>>>
>>> What you're asking for is a tool that might take days to weeks to roll
>>> out in a decent form, and even then it will be doing guesswork (because
>>> that's simply the nature of the beast when dealing with this problem),
>>> and then it will take a few more days to give it a frontend, to find
>>> defaults that -most- people -might- like, to debate whether it should
>>> be exposed properly: do you give iterations and discretization control
>>> options (puzzling all those customers who didn't study maths past the
>>> age of 11), or do you blackbox it and hope the TDs out there won't mind
>>> having to re-frontend it themself?
>>>
>>> These, and many other issues related to the dev process mean that, to
>>> get an uncertain solution to a problem that you very seldomly need to
>>> solve approximatively, will take days of dev time off from a schedule
>>> that could have been used for much, MUCH more important things.
>>>
>>> Be careful with what you ask, because you might get it, and so will the
>>> rest of us who had little use for all the time wasted on such thing.
>>>
>>> For the record: I can't find a decently precise tool of this kind in
>>> other packages I know how to use, and the one I've read about in a
>>> fairly expensive CAM package (I was researching related problems just a
>>> few months back and bumped into several forums while googling), was
>>> being hammered by the userbase because it would take seconds to minutes
>>> to return the correct splices. Does this mean that at least 5 major SW
>>> companies out there are arrogant lazy bastards, or might it mean that
>>> not everything is necessarily as simple as some people seem to think it
>>> is?
>>>
>>> A little more respect for the Soft developers posting on the list (last
>>> time I checked their time to do it isn't paid), when you're obviously
>>> out of your depth being unable to read that Halfy's answer was pretty
>>> good, would also be a nice addition to the next email.
>>>
>>> cheers
>>> Raff
>>>
>>> P.S.
>>> :) :( :/ ;) 0_o ( )( ) :D
>>> here's a few free smileys, feel free to use them wherever you prefer in
>>> the mail to make it funnier and less harsh, since it seems that a post
>>> without smileys, even if in context and reasonable, is always too harsh
>>> or insulting these days ;) :) :D ^__^
>>>
>>> ******************************
>>> | Raffaele Fragapane |
>>> | Rising Sun Pictures |
>>> | "Remember, TD is for TopDog" |
>>> ******************************
>>>
>>>
>>>
>>> Mike Werckle wrote:
>>>
>>> > The issue Halfdan, is not about your knowledge-- it's about XSI
>>> > missing a fundamental feature and someone requesting an answer and
>>> > being ignored.
>>> >
>>> > On 7/13/06, * Halfdan Ingvarsson* <hingvars(at)softimage.com
>>> > <mailto:hingvars(at)softimage.com>> wrote:
>>> >
>>> > A curve isn't just a curve.
>>> >
>>> > 2D bezier curve intersection, a la Flash, can be done
>>> analytically
>>> > using de Casteljau's algorithm extremely efficiently. 3D NURBS
>>> > curve intersection with an epsilon tolerance, is a completely
>>> > differen matter. It *can* be done analytically but is not
>>> > guaranteed to be particularly stable. So it is usually solved
>>> > iteratively.
>>> >
>>> > Basically you iterate on a per-half segment basis over one curve
>>> > (using each half of a pair of knots) and iteratively find the
>>> > closest point on the other curve and keep the points that are
>>> > closed than your epsilon. Even that's not guaranteed to work
>>> > completely if the curves are parallel.
>>> >
>>> > Then again, I'm probably completely wrong. Mike, why don't
>>> > you enlighten us all?
>>> >
>>> > - ½
>>> >
>>> >
>>> > -----Original Message-----
>>> > *From:* owner-xsi(at)Softimage.COM
>>> > <mailto:owner-xsi(at)Softimage.COM>
>>> > [mailto:owner-xsi(at)Softimage.COM
>>> > <mailto:owner-xsi(at)Softimage.COM>]*On Behalf Of *Mike Werckle
>>> > *Sent:* Thursday, 13 July, 2006 13:39
>>> > *To:* XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>
>>> > *Subject:* Re: intersecting curves
>>> >
>>> > Clearly Brad, if you want to be doing something as difficult
>>> > as intersecting curves you should be using flash.
>>> >
>>> > On 7/11/06, *brad friedman* < xsibrad(at)fie.us
>>> > <mailto:xsibrad(at)fie.us>> wrote:
>>> >
>>> > By "point" do you mean the closest knot? or closest
>>> > arbitrary "u" value on a given segment? If you mean the
>>> > closest "u" value on the given curve segment... then
>>> thats
>>> > what I'm after (I don't mind specifying a threshold...
>>> > thats what maya and power animator do after all). Can
>>> XSI
>>> > find this for me? Or do I have to code it myself?
>>> >
>>> > -brad
>>> >
>>> >
>>> > */Halfdan Ingvarsson < hingvars(at)Softimage.COM
>>> > <mailto:hingvars(at)Softimage.COM>>/* wrote:
>>> > Intersecting NURBS curves analytically is a complete
>>> beast
>>> > and best avoided. Your best bet is to do a binary seach
>>> > for a closest point on a segment-by-segment basis.
>>> >
>>> > -
>>> >
>>> > -----Original Message-----
>>> > *From:* owner-xsi(at)Softimage.COM
>>> > <mailto:owner-xsi(at)Softimage.COM>
>>> > [mailto:owner-xsi(at)Softimage.COM
>>> > <mailto:owner-xsi(at)Softimage.COM> ]* On Behalf Of
>>> > *bradd friedman
>>> > *Sent:* Tuesday, 11 July, 2006 13:31
>>> > *To:* xsi(at)Softimage.COM <mailto:xsi(at)Softimage.COM>
>>> > *Subject:* intersecting curves
>>> >
>>> > I posted this question a year ago... just want to
>>> make
>>> > sure no one found a good solution since.
>>> >
>>> > Is there a good way to find the intersection between
>>> > two curves in XSI at this point? I want to
>>> eventually
>>> > just cut curves up by their intersection points...
>>> but
>>> > one thing at a time :)
>>> >
>>> > -brad
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >----------------------------------------------------------------------
>>> -
>>> >-
>>> >
>>> >No virus found in this incoming message.
>>> >Checked by AVG Free Edition.
>>> >Version: 7.1.394 / Virus Database: 268.9.10/387 - Release Date:
>>> >7/12/2006
>>> >
>>> >
>>>
>>> ---
>>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>>> body:
>>> unsubscribe xsi
>>>
>>
>>
>>
>>
>> ---
>> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
>> body:
>> unsubscribe xsi
>>
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in
> body:
> unsubscribe xsi
>
>
>
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
