 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Goal: To have a CSG shaped tire follow the shape of an isosurface ground
during an animation.
Method:
I wrote a macro that will take the object identifier and a resolution
attribute (float value). I then create an array of points that fill the
max and min extents of the object, spacing them at the value given by
resolution. I then iterate through the list and remove all the points
outside the actual object (using the inside function).
I then place the object (and the point array) below the lowest level of the
ground (i.e. if the grounds lowest point is -.5, I place the wheel at -.6.
I then test each point in the array to determine how far I need to
translate the wheel up to get all the points outside the ground. I then
translate all the points and the wheel that amount.
I repeat the above process for each frame of the animation.
Problem:
The method is not entirely accurate.
The method is not very fast.
Question:
Is there a better way to do this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So you're creating a 3d array of points (with certain x, y, and z
spacing), and removing those points above the surface?
Why not just create a 2d array (with certain x and z spacing) and use
trace() to find the y values of each grid point?
But I may have misunderstood you...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I started by trying to get trace to work, but the values I got back were
wrong. If I traced a point to the surface of the ground (with a direction
vector of <0,-1,0>, I would get very wrong y values if the ground was
perfectly flat. The best example I can give is in the code I posted
earlier (see thread titled "Collision Detection"). In that example, I had
a ball going over some spheres. In the case that the ball was directly
above the ground spheres, I would recieve a y offset that was close to
double what it should have been.
Maybe I just need a better understanding of how trace works and how to use
it. I would love to explore that, but have had trouble locating resources
or tutorials.
Mike
Rune wrote:
>So you're creating a 3d array of points (with certain x, y, and z
>spacing), and removing those points above the surface?
>
>Why not just create a 2d array (with certain x and z spacing) and use
>trace() to find the y values of each grid point?
>
>But I may have misunderstood you...
>
>Rune
>--
>3D images and anims, include files, tutorials and more:
>rune|vision: http://runevision.com (updated July 12)
>POV-Ray Ring: http://webring.povray.co.uk
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Getting a good value from trace is not the easiest thing in the world. For
my latest IRTC entry I used trace to get locations to place boulders, and
just about everything else, in a landscape. You have to start with huge y
values ( far above the surface ) and point down:
#declare Land = height_field {
png "texland.png"
smooth
translate <-.5, 0.25, -.5>
texture { texLand }
scale <1e5, 4500, 1e5>
}
#declare csBase = <4500, 34000, 6500>;
#declare csNorm = <0,0,0>;
#declare cSrc = trace(Land, csBase, -y, csNorm)+y*5;
You have to take care not to miss the HF (vlength(csNorm)=0). You should
get the altitude of the ground at that point. Keep in mind that the entire
surface must be defined under one variable, using union and merge where
necessary. If you define an isosurface using a known y=f(x,z) function and
trace() gives you an answer inconsistent with a verifiable calculation,
that's a bug and needs to be reported to the POV Team. Use
#debug concat("Intersection found at ",vstr(3,cSrc,",",0,3)," .\n")
to check your work.
"Mike" <mla### [at] yahoo com> wrote in message
news:web.3d59bd05ca87489de9d3dc080@news.povray.org...
> I started by trying to get trace to work, but the values I got back were
> wrong. If I traced a point to the surface of the ground (with a direction
> vector of <0,-1,0>, I would get very wrong y values if the ground was
> perfectly flat. The best example I can give is in the code I posted
> earlier (see thread titled "Collision Detection"). In that example, I had
> a ball going over some spheres. In the case that the ball was directly
> above the ground spheres, I would recieve a y offset that was close to
> double what it should have been.
>
> Maybe I just need a better understanding of how trace works and how to use
> it. I would love to explore that, but have had trouble locating resources
> or tutorials.
>
> Mike
>
>
> Rune wrote:
> >So you're creating a 3d array of points (with certain x, y, and z
> >spacing), and removing those points above the surface?
> >
> >Why not just create a 2d array (with certain x and z spacing) and use
> >trace() to find the y values of each grid point?
> >
> >But I may have misunderstood you...
> >
> >Rune
> >--
> >3D images and anims, include files, tutorials and more:
> >rune|vision: http://runevision.com (updated July 12)
> >POV-Ray Ring: http://webring.povray.co.uk
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Is there a better way to do this?
Date: 19 Aug 2002 14:16:41
Message: <3d613609@news.povray.org>
|
|
|
| |
| |
|
|
In article <3d6121af@news.povray.org> , "David Wallace"
<dar### [at] earthlinknet> wrote:
> If you define an isosurface using a known y=f(x,z) function and
> trace() gives you an answer inconsistent with a verifiable calculation,
> that's a bug and needs to be reported to the POV Team.
No, it is not a bug. The max_gradient setting is simply wrong.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
max_gradient is an issue with isosurfaces only, with standard HF's (which I
suspect are meshes) it is not. A parametric mesh has no such limitations
and can be set up as y=f(x,z) very easily (memory use is another matter,
though). You can still verify traces.
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d613609@news.povray.org...
> In article <3d6121af@news.povray.org> , "David Wallace"
> <dar### [at] earthlinknet> wrote:
>
> > If you define an isosurface using a known y=f(x,z) function and
> > trace() gives you an answer inconsistent with a verifiable calculation,
> > that's a bug and needs to be reported to the POV Team.
>
> No, it is not a bug. The max_gradient setting is simply wrong.
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d63e737@news.povray.org>,
"David Wallace" <dar### [at] earthlinknet> wrote:
> max_gradient is an issue with isosurfaces only, with standard HF's (which I
> suspect are meshes) it is not. A parametric mesh has no such limitations
> and can be set up as y=f(x,z) very easily (memory use is another matter,
> though). You can still verify traces.
The message specifically mentioned isosurfaces. Meshes and height fields
(which are a form of mesh internally, as you suspected) obviously don't
have this kind of problem. With some other objects "sturm" could be a
problem instead.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you all for your help with this issue.
After reviewing traces and doing some work with them, I think I will stick
with my original solution. The main reason is that if I decide to make the
tire out of a mesh instead of a CSG, the method I originaly put together
will work. Also, I can more easily deform the mesh to make it look like an
air filled rubber tire.
Mike wrote:
>Goal: To have a CSG shaped tire follow the shape of an isosurface ground
>during an animation.
>
>Method:
>I wrote a macro that will take the object identifier and a resolution
>attribute (float value). I then create an array of points that fill the
>max and min extents of the object, spacing them at the value given by
>resolution. I then iterate through the list and remove all the points
>outside the actual object (using the inside function).
>I then place the object (and the point array) below the lowest level of the
>ground (i.e. if the grounds lowest point is -.5, I place the wheel at -.6.
>I then test each point in the array to determine how far I need to
>translate the wheel up to get all the points outside the ground. I then
>translate all the points and the wheel that amount.
>I repeat the above process for each frame of the animation.
>
>Problem:
>The method is not entirely accurate.
>The method is not very fast.
>
>Question:
>Is there a better way to do this?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
