 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think what you are suggesting is an isosurface solving method for all
objects to allow non-linear transformations to be used...right?
This would be possible for many objects, but not for all...for example,
meshes wouldn't be easy(though you could probably do some kind of
proximity calculation).
Also, you wouldn't want to use the isosurface solving method to
completely replace the existing method, since it is sometimes slower and
less accurate. However, as an option, and even if only available for
some objects, it could potentially be very useful.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
From: Wlodzimierz ABX Skiba
Subject: Re: next step (long and perhaps nothing interesting)
Date: 17 Nov 2000 07:30:31
Message: <3a1524e7@news.povray.org>
|
|
|
| |
| |
|
|
Chris Huff wrote in message ...
> I think what you are suggesting is an isosurface solving method for
all
> objects to allow non-linear transformations to be used...right?
right
> This would be possible for many objects, but not for all...for
example,
> meshes wouldn't be easy(though you could probably do some kind of
> proximity calculation).
yes, there could be checking for proper mesh
i.e. looking for declaration of inside_vector or something
> However, as an option, and even if only available for
> some objects, it could potentially be very useful.
especially for this users with small perception of math
ABX
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: next step (long and perhaps nothing interesting)
Date: 17 Nov 2000 10:25:33
Message: <3a154ded@news.povray.org>
|
|
|
| |
| |
|
|
In povray.unofficial.patches Chris Huff <chrishuff@mac.com> wrote:
: Also, you wouldn't want to use the isosurface solving method to
: completely replace the existing method, since it is sometimes slower and
: less accurate.
Specially with meshes. I suppose that if you substituted a big mesh
with a bunch of isosurfaces, your rendering time will go to the roof :)
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
"The derivative of sin(2x) is cos(2x)" - Matt Giwer
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Specially with meshes. I suppose that if you substituted a big mesh
> with a bunch of isosurfaces, your rendering time will go to the roof :)
>
Then again, you could forgo the isosurface method for meshes, and do the
non-linear transformations just on the vertices (after all, isn't that the usual
method of doing it - tessellating to a mesh and transforming the vertices?)
--
Margus Ramst
Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A155772.F7735710@peak.edu.ee>, Margus Ramst
<mar### [at] peakeduee> wrote:
> Then again, you could forgo the isosurface method for meshes, and do
> the non-linear transformations just on the vertices (after all, isn't
> that the usual method of doing it - tessellating to a mesh and
> transforming the vertices?)
That is what I have heard...POV is the only 3D software I have any
experience with.
Subdivision for meshes would also be nice...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a1524e7@news.povray.org>, "Wlodzimierz ABX Skiba"
<abx### [at] abxartpl> wrote:
> yes, there could be checking for proper mesh
> i.e. looking for declaration of inside_vector or something
Insideness checking won't be enough, the isosurface solving method
requires a continuously changing function, so you would need something
which changes depending on distance from the surface of the mesh and
which has a different sign on the inside of the mesh than on the outside.
A proximity function which decreases/increases linearly from 0 at the
surface of the mesh, negative "inside" the mesh and positive "outside"
the mesh would probably work quite well, but be slow, especially for
large meshes, and not exactly easy to code...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Nov 2000 19:13:22 -0500, Chris Huff <chr### [at] maccom>
wrote:
>A proximity function which decreases/increases linearly from 0 at the
>surface of the mesh, negative "inside" the mesh and positive "outside"
>the mesh would probably work quite well, but be slow, especially for
>large meshes, and not exactly easy to code...
Actually a proximity function for meshes wouldn't be that slow. Come
to think about it, you wouldn't need to trace any rays to find the
distance to the mesh at any point in space.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <8ujb1ts0ro5h8l41asccr9rvaro1qgpnip@4ax.com>, Peter Popov
<pet### [at] usanet> wrote:
> Actually a proximity function for meshes wouldn't be that slow. Come
> to think about it, you wouldn't need to trace any rays to find the
> distance to the mesh at any point in space.
It would be speedy compared to the current "shoot a bunch of samples"
method, but compared to a sphere or box proximity function, it certainly
would be slow.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 17 Nov 2000 20:18:08 -0500, Chris Huff <chr### [at] maccom>
wrote:
>> Actually a proximity function for meshes wouldn't be that slow. Come
>> to think about it, you wouldn't need to trace any rays to find the
>> distance to the mesh at any point in space.
>
>It would be speedy compared to the current "shoot a bunch of samples"
>method, but compared to a sphere or box proximity function, it certainly
>would be slow.
LOL yeah. Still, with the current octree optimisation of meshes, it
could be significantly sped up. I'll think about it.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <562f1t0o0lf0mju6t1qi0afrckf1q9k0vk@4ax.com>, Peter Popov
<pet### [at] usanet> wrote:
> LOL yeah. Still, with the current octree optimisation of meshes, it
> could be significantly sped up. I'll think about it.
And I will get back to working on the per-object proximity calculation
stuff...my last attempt kind of stalled. This is one area where it would
be *extremely* helpful to have C++...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
