 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A recent discussion about using marching cubes to turn a blob into a mesh
got me thinking...
Currently the isosurface renders slowly. I have a proposition:
Could we make a new object, maybe named iso_mesh, which looks exactly the
same as an isosurface in POV code, but is transformed to a mesh (via
marching cubes) before rendering. This could potentially greatly
speed up the rendering of an isosurface (of course, at the cost of image
quality and memory usage). I'll maybe work on it eventually, but I'm so
busy with other projects that it would be a long time before I could get
started, and by then maybe something more interesting would have come up
and I'd forget about it. Thoughts? Anyone interested in trying it?
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Currently the isosurface renders slowly. I have a proposition:
> Could we make a new object, maybe named iso_mesh, which looks exactly the
> same as an isosurface in POV code, but is transformed to a mesh (via
> marching cubes) before rendering? This could potentially greatly
Yes, I'm sure you could. And should. I see the future of POV depending on
triangles. If you don't start making objects out of triangles you'll never
take POV as far as the bigger packages (unless you don't mind making the
rendering time longer, which I don't like).
> speed up the rendering of an isosurface (of course, at the cost of image
> quality and memory usage). I'll maybe work on it eventually, but I'm so
Of course it will use more memory, but I don't think the quality of the image
will suffer. If you do it like bicubic patches do it, then it won't be
noticeable, unless too low a UV setting is used.
> busy with other projects that it would be a long time before I could get
> started, and by then maybe something more interesting would have come up
> and I'd forget about it. Thoughts? Anyone interested in trying it?
It definitely needs to be done. I propose a new syntax for objects to be made
effective in version 5.0 (seeing as version 3.5 is just an official
superpatch, and 4.0 is just a c++ rewrite). My suggested syntax is as
follows:
(example)
[before]
sphere {location, radius[, strength] texture}
[new syntax]
sphere
{
location, radius[, strength] texture
triangles on smoothen on
resolution N (or) resolution <x,y,z>
}
These three new commands would be made available to all pov objects. The
'triangles on' and 'smooth on' would be operated like 'hollow on' and other
similar instructions. The idea is that with 'triangles on' we tell pov to
forget about making the sphere like it used to and make it out of triangles,
using methods like Uwe Zimmerman has implemented. 'smoothen on' should be
self-explanatory. The 'resolution [N]/[<x,y,z>]' is meant to tell pov to make
the object out of N triangles, or to break it down into <x,y,z> pieces (like
Chris Colefax's explode.inc) and figure the triangles from that (I don't know
which option would be better, or if both could be implemented). The idea of
the triangle system is both to decrease rendering times, and to make the 3d
accelaration video cards of use to pov users. Also, this allows for
deformations like bend, twist, vortex, and displacement mapping, and so much
more, without having to do it through the isosurface patch. The benefit of
this being optional is that without the flags set to on, pov proceeds the
older, slower, more precise, less memory-consuming methods that we know and
love today. Please comment on the do-ability of this.
--
Anthony L. Bennett
http://welcome.to/TonyB
Graphics rendered
by the Dreamachine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I fully agree. Some purists will probably flame me for saying so. ;-)
Then if you mix this with the ability to put a frame-rendering loop in
POV code (to avoid parsing and tesselating for each frame), POV has the
potential to do some very high-speed animation.
-Nathan
TonyB wrote:
>
> It definitely needs to be done. I propose a new syntax for objects to be made
> effective in version 5.0 (seeing as version 3.5 is just an official
> superpatch, and 4.0 is just a c++ rewrite). My suggested syntax is as
> follows:
>
> (example)
>
> [before]
> sphere {location, radius[, strength] texture}
>
> [new syntax]
> sphere
> {
> location, radius[, strength] texture
> triangles on smoothen on
> resolution N (or) resolution <x,y,z>
> }
>
> These three new commands would be made available to all pov objects. The
> 'triangles on' and 'smooth on' would be operated like 'hollow on' and other
> similar instructions. The idea is that with 'triangles on' we tell pov to
> forget about making the sphere like it used to and make it out of triangles,
> using methods like Uwe Zimmerman has implemented. 'smoothen on' should be
> self-explanatory. The 'resolution [N]/[<x,y,z>]' is meant to tell pov to make
> the object out of N triangles, or to break it down into <x,y,z> pieces (like
> Chris Colefax's explode.inc) and figure the triangles from that (I don't know
> which option would be better, or if both could be implemented). The idea of
> the triangle system is both to decrease rendering times, and to make the 3d
> accelaration video cards of use to pov users. Also, this allows for
> deformations like bend, twist, vortex, and displacement mapping, and so much
> more, without having to do it through the isosurface patch. The benefit of
> this being optional is that without the flags set to on, pov proceeds the
> older, slower, more precise, less memory-consuming methods that we know and
> love today. Please comment on the do-ability of this.
>
> --
> Anthony L. Bennett
> http://welcome.to/TonyB
>
> Graphics rendered
> by the Dreamachine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I fully agree. Some purists will probably flame me for saying so. ;-)
I'm glad you see things this way.
> Then if you mix this with the ability to put a frame-rendering loop in
> POV code (to avoid parsing and tesselating for each frame), POV has the
> potential to do some very high-speed animation.
That would be very cool. So do you like my proposed syntax?
--
Anthony L. Bennett
http://welcome.to/TonyB
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm, good idea, but what is the "strength" for the sphere? Also,
wouldn't a high enough resolution mesh take about as long to calculate
as the usual isosurface?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe, but: 1) for test renders you could use a lower resolution mesh;
2) for animatins you could do the tesselation once for the animation instead
of for every frame; and 3) possibly after you do the tesselation you could
save the mesh to a temporary binary file (platform independence of this
binary is not necessary as it is only temporary and is intended for use only
on the system on which it was created) and re-load it later.
-Nathan
Chris Huff wrote:
>
> Hmm, good idea, but what is the "strength" for the sphere? Also,
> wouldn't a high enough resolution mesh take about as long to calculate
> as the usual isosurface?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 22 Jul 1999 18:14:35 -0400, Nathan Kopp <Nat### [at] Kopp com>
wrote:
>A recent discussion about using marching cubes to turn a blob into a mesh
>got me thinking...
>
>Currently the isosurface renders slowly. I have a proposition:
>Could we make a new object, maybe named iso_mesh, which looks exactly the
>same as an isosurface in POV code, but is transformed to a mesh (via
>marching cubes) before rendering. This could potentially greatly
>speed up the rendering of an isosurface (of course, at the cost of image
>quality and memory usage). I'll maybe work on it eventually, but I'm so
>busy with other projects that it would be a long time before I could get
>started, and by then maybe something more interesting would have come up
>and I'd forget about it. Thoughts? Anyone interested in trying it?
Better try marching triangles or some other method. Marching cubes
has software patent issues. You can find marching triangle info at
http://www.ee.surrey.ac.uk/Research/VSSP/3DVision.html. You may also
want to consider adapting subdivision surface methods.
Jerry Anning
clem "at" dhol "dot" com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks for the heads-up.
Not to start a huge discussion.... but as a programmer I find software
patents so annoying. I have this sinking feeling that in the future
whenever I try to do something, all of my tools to complete the task
will be unavailable because somebody patented them.
Oh, well... in this case, though, it seems like marching triangles will be
better anyways (faster, fewer triangles, etc).
-Nathan
Jerry Anning wrote:
>
> Better try marching triangles or some other method. Marching cubes
> has software patent issues. You can find marching triangle info at
> http://www.ee.surrey.ac.uk/Research/VSSP/3DVision.html. You may also
> want to consider adapting subdivision surface methods.
>
> Jerry Anning
> clem "at" dhol "dot" com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oh, well... in this case, though, it seems like marching triangles will be
> better anyways (faster, fewer triangles, etc).
That is so cool. 'There is always a better way...' I remember someone saying
that. Anyway, that is so interesting... the marching cubes sure add a lot of
unnecessary triangles, huh? It reminds me of my cloth... the original formulas
sure added a lot of unnecessary computations as well. Instead of doing the
adjustments at the beginning, you just post-process the results with some
small formulae.
May simple and quick always be the right answer! It's great when we learn
something that let's us know "you don't need to upgrade your hardware, just
your software".
--
Anthony L. Bennett
http://welcome.to/TonyB
Graphics rendered
by the Dreamachine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] Koppcom> wrote in message
news:3797B87C.F79E8DF3@Kopp.com...
> Thanks for the heads-up.
>
> Not to start a huge discussion.... but as a programmer I find software
> patents so annoying. I have this sinking feeling that in the future
> whenever I try to do something, all of my tools to complete the task
> will be unavailable because somebody patented them.
Well, we just have to start distribute povray from sweden then because we
don't have patents on algorithms here. :)
It has been done for a couple of mp3-encoders who use that fast fraunhofer
algorithm or what ever it's called.
/Anders
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
