 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi everybody. I was wondering why POV doesn't have a displacement maps
feature like other 3d packages. This would allow cool stuff like
spherical heightfields and what-not. Could such a thing be implemented
in POV? If not, why?
Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This would be excellent!!!
Anthony Bennett wrote in message <36FCDA10.B750D742@panama.phoenix.net>...
>Hi everybody. I was wondering why POV doesn't have a displacement maps
>feature like other 3d packages. This would allow cool stuff like
>spherical heightfields and what-not. Could such a thing be implemented
>in POV? If not, why?
>
>Thanks.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not a good programmer so this is out of my league, but maybe somebody
would like to have a look as this postscript paper I found on displacement
mapping.
Site http://graphics.stanford.edu/papers/displace/
Paper http://graphics.stanford.edu/papers/displace/displace.ps
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think this has been discussed before some time ago, but I dont' remember
the thread. Anyway, the main problem is that displacement mapping would
require the object to be converted into a mesh (like the current height
field). This is by no means easy, and I think it's impossible with objects
like julia fractals.
Object meshing would also allow non-linear transformations like twisting,
bending and other cool things.
Margus
Anthony Bennett wrote in message <36FCDA10.B750D742@panama.phoenix.net>...
>Hi everybody. I was wondering why POV doesn't have a displacement maps
>feature like other 3d packages. This would allow cool stuff like
>spherical heightfields and what-not. Could such a thing be implemented
>in POV? If not, why?
>
>Thanks.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, it could be done... all you have to do is specify the bounds of an
object and an XYZ threshold. If there is an object intersection routine in
POV-Ray (which there has to be somewhere!) then you could make a patch of
POV-Ray to allow keyword access to such a function. Then all you have to do
is an ordered test from the top of the bounding box to the bottom calling
the routine. If it returns 1 then you know that the point lies on the
surface of the object, so you can join the previous row of triangles to the
current and so on... And there you have it, a MESH! WOO HOO!!!
There is a plug-in for MAX called MAXMath which does exactly that. I've
also made a small program that does it. It's not that hard (well, I've
never done the meshing before, but I'm sure some talented programmer out
there could).
Not sure about fractals though... Hmm........
Anyway, hope this helps! Oh, and also, you'd have to make some new mapping
modes, like shrink-wrap to make it realy useful for displaycement mapping,
or alternatively, you can have it as part of the texture statement.
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Believe you've got the mesh thing right; that is, about it being the
reason the displacement hasn't been used.
Most primitives in POV being non-polygon and that conversion you mention
necessary means extra computing.
Anyone want to bet someone more in the know backs me up? Or maybe I will
lose my shirt in this gamble.
Hey, we'll all have computers beyond these puny 500MHz, 256Meg RAM
machines someday though, right? ha-ha, ah, uh...
Lance Birch wrote:
>
> Well, it could be done... all you have to do is specify the bounds of an
> object and an XYZ threshold. If there is an object intersection routine in
> POV-Ray (which there has to be somewhere!) then you could make a patch of
> POV-Ray to allow keyword access to such a function. Then all you have to do
> is an ordered test from the top of the bounding box to the bottom calling
> the routine. If it returns 1 then you know that the point lies on the
> surface of the object, so you can join the previous row of triangles to the
> current and so on... And there you have it, a MESH! WOO HOO!!!
>
> There is a plug-in for MAX called MAXMath which does exactly that. I've
> also made a small program that does it. It's not that hard (well, I've
> never done the meshing before, but I'm sure some talented programmer out
> there could).
>
> Not sure about fractals though... Hmm........
>
> Anyway, hope this helps! Oh, and also, you'd have to make some new mapping
> modes, like shrink-wrap to make it realy useful for displaycement mapping,
> or alternatively, you can have it as part of the texture statement.
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/homepage.htm
mailto:inv### [at] aol com?Subject=PoV-News
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, it shouldn't be TOOOOOO system intensive really... I mean, that's
what MAX does, it uses all triangles afterall... The displacements are
really quite quick... It's not hard for it to compute it necessarily, but it
will use a fair bit of memory.
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote:
>
> Well, it shouldn't be TOOOOOO system intensive really... I mean, that's
> what MAX does, it uses all triangles afterall... The displacements are
> really quite quick... It's not hard for it to compute it necessarily, but it
> will use a fair bit of memory.
>
> --
> Lance.
>
> ---
> For the latest 3D Studio MAX plug-ins, images and much more, go to:
> The Zone - http://come.to/the.zone
I can write a pov scene that has a camera, lights and 2,000,000
spheres in a file that takes up less that 200 bytes on my hard drive.
Can you honestly say you can do that with Max ?
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, I can. It's called MAXScript. Just like a macro in POV-Ray.
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But the problem would be the fact that they are meshes with the problems
inherent in meshes. Mainly straight segments on the edges of things that are
smooth like spheres. This is one of the beauties of POVRay and similar
programs, when you specify a sphere, you can zoom in as close as you like
and it is still a sphere, no straight edges.
MAX is so much faster than POVRay because it is not a ray-tracer. This has
nothing to do with meshes/primitives. I have nothing against MAX, I just
prefer ray-tracing and real primitives.
I'll re-issue Ken's challenge, but the proviso is that I can zoom to any
position and never see a straight line without having to fiddle the scene!
Regards
Gordon
<gbe### [at] birdcameroncomau>
Lance Birch wrote in message <36fdfddd.0@news.povray.org>...
>Yes, I can. It's called MAXScript. Just like a macro in POV-Ray.
>
>--
>Lance.
>
>
>---
>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>MAX is so much faster than POVRay because it is not a ray-tracer.
Funny I always found max much slower, and harder to get the smae kind of
quality of povray, I have a tendency to model complex mesh objects in
Truspace 4 or Max then rennder in POVray
Rick
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, that's interesting, cause I've always found it faster... in both
modelling and rendering. Just going back to the point before though, I
understand that inherently MAX is faster because it is a scan-line renderer,
but you also have to remember that MAX has adaptive degredation, so no
matter how far you zoom in it will compensate by interpolating the faces and
recalculating the object. This is especially useful in NURBS modelling (for
obvious reasons).
MAX can also do raytracing though, it just uses the scan-line renderer, but
when it calls the texturing function, that's where the raytracing is done
(and it is very accurate BTW, it can do a lot of really cool things too,
like reflective defusion, distance bluring, flurescence etc).
Most of the time I'm modelling with NURBS, where it is impossible to have a
real primitive. Personally of course I like the idea of real primitives
because they are accurate and allow easy booleaning.
BUT! Back to the question at hand of course (LOL, "you know you've been
raytracing too long when you get in a flame war over rendering programs..."
he he he)
It still, if you didn't want to do it the mesh way that is, should be
possible to incorporate this feature into POV-Ray. I know the Isosurface
patch can do it with its bump mapping (as in, formula based displacement),
so surely if you created a few new mapping types and created a displacement
function based on the intensity of an image it should be possible... Of
course there's no way I could do it, I'm not a brilliant programmer like all
the poeple on the POV-Team :-)
Back to the mesh idea though, as long as the function was well written there
shouldn't be problems with surface normals... I don't think that it would
be too hard (given a person that is a good programmer) to create a function
that would auto-interpolate an object to the correct amount... Of course
this kind of advanced macroing would require some extra keywords to be built
into POV-Ray, such as object intersection, etc etc etc.
Anyway, just a thought... Also, isn't there an external program which can do
this? I can't remember the name of it... and it's only to meshes of
course...
--
Lance.
BTW, anyway how wants to see what MAX can do, go to
www.fortunecity.com/skyscraper/parallax/359/maxgallery.html
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Did anyone notice the link I posted (second reply)?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That does surprise me. Just how slow is MAX? I regularly do POVRay renders
that take 20 - 100 hours for a single frame(I am talking about 1025x768
AA=0.001, 10,000+ objects), does MAX take that long? How do people do the
neat animations in a realistic time?
Regards
Gordon
Lance Birch wrote in message <36fea482.0@news.povray.org>...
>Hmm, that's interesting, cause I've always found it faster... in both
>modelling and rendering. Just going back to the point before though, I
>understand that inherently MAX is faster because it is a scan-line
renderer,
>but you also have to remember that MAX has adaptive degredation, so no
>matter how far you zoom in it will compensate by interpolating the faces
and
>recalculating the object. This is especially useful in NURBS modelling
(for
>obvious reasons).
>
>MAX can also do raytracing though, it just uses the scan-line renderer, but
>when it calls the texturing function, that's where the raytracing is done
>(and it is very accurate BTW, it can do a lot of really cool things too,
>like reflective defusion, distance bluring, flurescence etc).
>
>Most of the time I'm modelling with NURBS, where it is impossible to have a
>real primitive. Personally of course I like the idea of real primitives
>because they are accurate and allow easy booleaning.
>
>BUT! Back to the question at hand of course (LOL, "you know you've been
>raytracing too long when you get in a flame war over rendering programs..."
>he he he)
>
>It still, if you didn't want to do it the mesh way that is, should be
>possible to incorporate this feature into POV-Ray. I know the Isosurface
>patch can do it with its bump mapping (as in, formula based displacement),
>so surely if you created a few new mapping types and created a displacement
>function based on the intensity of an image it should be possible... Of
>course there's no way I could do it, I'm not a brilliant programmer like
all
>the poeple on the POV-Team :-)
>
>Back to the mesh idea though, as long as the function was well written
there
>shouldn't be problems with surface normals... I don't think that it would
>be too hard (given a person that is a good programmer) to create a function
>that would auto-interpolate an object to the correct amount... Of course
>this kind of advanced macroing would require some extra keywords to be
built
>into POV-Ray, such as object intersection, etc etc etc.
>
>Anyway, just a thought... Also, isn't there an external program which can
do
>this? I can't remember the name of it... and it's only to meshes of
>course...
>
>--
>Lance.
>
>BTW, anyway how wants to see what MAX can do, go to
>www.fortunecity.com/skyscraper/parallax/359/maxgallery.html
>
>---
>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
MAX isn't a slow renderer at all, it's very fast actually.
Hmm, could take as little as 5 minutes depending on the scene (@ 1024x768
that is, some of mine take only a few minutes to render to that resolution).
I did a 5 minute long rendering once at full TV resolution (PAL) and it took
around 36 hours, but that animation was very simple really. The most
complex animation I've done was a 30-seconder (@ full PAL res) and it took
about a week of rendering because of the complex objects and texturing
(including raytracing).
It really all depends on how well someone can optimise a scene. For
example, you don't use raytracing where it isn't needed... Like
non-reflective or non-refractive surfaces don't need to be raytraced, so it
just scan-lines them. It also has a great adaptive anit-aliaser.
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My query was based on the statement that POVRay often/usually renders faster
than MAX, I though that was surprising.
Thanks for the info,
Gordon
Lance Birch wrote in message <36ff605b.0@news.povray.org>...
>MAX isn't a slow renderer at all, it's very fast actually.
>
>Hmm, could take as little as 5 minutes depending on the scene (@ 1024x768
>that is, some of mine take only a few minutes to render to that
resolution).
>I did a 5 minute long rendering once at full TV resolution (PAL) and it
took
>around 36 hours, but that animation was very simple really. The most
>complex animation I've done was a 30-seconder (@ full PAL res) and it took
>about a week of rendering because of the complex objects and texturing
>(including raytracing).
>
>It really all depends on how well someone can optimise a scene. For
>example, you don't use raytracing where it isn't needed... Like
>non-reflective or non-refractive surfaces don't need to be raytraced, so it
>just scan-lines them. It also has a great adaptive anit-aliaser.
>
>--
>Lance.
>
>
>---
>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It does? Since when? IT'S MUCH FASTER THAN POV-RAY!!!
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 28 Mar 1999 12:46:55 +1000, Lance Birch <lan### [at] usanet> wrote:
>Well, it could be done... all you have to do is specify the bounds of an
>object and an XYZ threshold. If there is an object intersection routine in
>POV-Ray (which there has to be somewhere!) then you could make a patch of
>POV-Ray to allow keyword access to such a function. Then all you have to do
>is an ordered test from the top of the bounding box to the bottom calling
>the routine. If it returns 1 then you know that the point lies on the
>surface of the object, so you can join the previous row of triangles to the
>current and so on... And there you have it, a MESH! WOO HOO!!!
I don't believe this will work as well as you might think, because it's not
always obvious even to a human how to connect the dots to make a surface, let
alone to a computer, but there are other ways of creating a mesh from an
implicit surface. Once you do create a mesh, you'll want to have a mesh that
you can use reliably in CSG as well.
The superpatch does have keyword access to the object intersection routines,
but I think it would be unacceptably slow. Better to implement something
like this in core code, especially because it's trivial to generate meshes
for some primitives.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch wrote in message <36ff7909.0@news.povray.org>...
>It does? Since when? IT'S MUCH FASTER THAN POV-RAY!!!
Read Rick's post, that is what I was replying to. I had already said that
MAX is faster, he objected that MAX is slower than POVRay so I was asking
for details as it seemed strange to me.
Gordon
>
>--
>Lance.
>
>
>---
>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>The Zone - http://come.to/the.zone
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <36ff84b0.0@news.povray.org>...
>
>I don't believe this will work as well as you might think, because it's not
>always obvious even to a human how to connect the dots to make a surface,
let
>alone to a computer, but there are other ways of creating a mesh from an
>implicit surface. Once you do create a mesh, you'll want to have a mesh
that
>you can use reliably in CSG as well.
>
>The superpatch does have keyword access to the object intersection
routines,
>but I think it would be unacceptably slow. Better to implement something
>like this in core code, especially because it's trivial to generate meshes
>for some primitives.
I have created a sampling macro (two, actually) using the trace() function;
it's not all that slow. But it only returns a point cloud. I once thought of
making a meshing macro (with the marching cubes system) but dropped the idea
due to lack of time. Marching triangles would be better, but I'm not
familiar with the principles. Anyway, all this would be much more viable
implemented in core code, having direct access to pattern functions for
displacement mapping.
BTW, Didn't somebody here mention, not so long ago, that he was working on a
meshing system for POV?
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all,
didn't mean to start a war!
but on, my machine I have had faster resultes with POVray compared to max,
admittadly i have only been trying quick scenes, not many objects etc.. ( a
few hundred or so)
but MAX tends to wipe out nearly everything my PC has, before you have even
done anything, and low system resources may be choking the render time up.
Rick
Gordon wrote in message <36ffa52e.0@news.povray.org>...
>
>Lance Birch wrote in message <36ff7909.0@news.povray.org>...
>>It does? Since when? IT'S MUCH FASTER THAN POV-RAY!!!
>
>Read Rick's post, that is what I was replying to. I had already said that
>MAX is faster, he objected that MAX is slower than POVRay so I was asking
>for details as it seemed strange to me.
>
>Gordon
>
>>
>>--
>>Lance.
>>
>>
>>---
>>For the latest 3D Studio MAX plug-ins, images and much more, go to:
>>The Zone - http://come.to/the.zone
>>
>>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ah yes, I see what you mean now. MAX uses a HEAP of memory to be fast
(because it's polygon based).
If you have less than 128Mb it runs slow (more than 128Mb is comfortable).
--
Lance.
---
For the latest 3D Studio MAX plug-ins, images and much more, go to:
The Zone - http://come.to/the.zone
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
