 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] koppcom> wrote:
: 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.
Here in Finland you can't patent algorithms or methods. You can only
patent real devices and such which have not been published before.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3797f5ff@news.povray.org> , "Anders Haglund"
<and### [at] hotmailcom> wrote:
> 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.
I think that goes for the whole European Union - we don't have such a
nonsense here in Germany either.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3797f5ff@news.povray.org> , "Anders Haglund"
> <and### [at] hotmailcom> wrote:
>
> > 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.
>
> I think that goes for the whole European Union - we don't have such a
> nonsense here in Germany either.
>
Yet! But trust the U.S. government to put pressure on the E.U. parlement
to recognize:
- mathematical patent (just let me patent PI and e, as well as the
addition)
- biological patent (you are all mine ! your blood is mine, all your
proteine are patented, all your DNA is patented
(by small chunk, so making a baby is a patent
violation of reusing patented material !)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The highest cost in rendering blobs, isosurfaces, or any other procedurally
defined surface is performing intersection tests for rays that miss the object.
This is why turning them into a mesh is such a cool idea. I mean the
intersection test is dead simple, and anyone who is serious about rendering
speed already has tons of memory!
But let me toss in another suggestion that might short-circuit the critics AND
keep the speed advantage. Let's compute the mesh and use it as a bounding
surface (i.e. we are 99.5% sure that the isosurface totally inside this mesh).
And, you could just render the mesh for test renders. This will totally reduce
the number wasted calculations, and keep the beauty of the isosurfaces at al
resolutions!
BUT I know that there are some guys out there thinking, "why not use the usual
bounding boxes?" The big deal about isosurfaces and blobs is the easy way you
can model "organic" shapes and seamlessly connected objects. Well, it seems to
me like these objects are full of holes or have tubes stucking out of them, so
the bounding box ends up being 60-80% empty, and you waste 60-80% of your
expensive intersection tests!
Just an idea!
In Him,
Ben
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
J. Grimbert wrote in message <37987EB2.A7AC92CC@atos-group.com>...
>Thorsten Froehlich wrote:
>>
>> In article <3797f5ff@news.povray.org> , "Anders Haglund"
>> <and### [at] hotmailcom> wrote:
>>
>> > 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.
>>
>> I think that goes for the whole European Union - we don't have such a
>> nonsense here in Germany either.
>>
>Yet! But trust the U.S. government to put pressure on the E.U. parlement
>to recognize:
> - mathematical patent (just let me patent PI and e, as well as the
>addition)
Someone HAS gotten a patent on a number! It is a large prime number, and as
such is useful for encryption. The person who got the patent on the number
did so to show how out of hand the patent process was.
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37987EB2.A7AC92CC@atos-group.com> , "J. Grimbert"
<jgr### [at] atos-groupcom> wrote:
>> I think that goes for the whole European Union - we don't have such a
>> nonsense here in Germany either.
>>
> Yet! But trust the U.S. government to put pressure on the E.U. parliament
> to recognize:
The EU and its member states are independent. The USA cannot blackmail the
EU or any of its member states. The economic power (superseding that of the
USA) of the EU and independence from USA markets doesn't put the USA in a
position to put up any pressure..the USA cannot afford a trade war with the
EU as this would seriously damage growth in the USA and no president/party
could survive it :-)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Birdsey wrote:
>
> But let me toss in another suggestion that might short-circuit the critics
AND
> keep the speed advantage. Let's compute the mesh and use it as a bounding
> surface (i.e. we are 99.5% sure that the isosurface totally inside this mesh).
> And, you could just render the mesh for test renders. This will totally reduce
> the number wasted calculations, and keep the beauty of the isosurfaces at al
> resolutions!
A very interesting idea! You could bound with a lower resolution mesh if
you use a slightly higher potential threshold.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Concave surfaces might be a problem.
Margus
Nathan Kopp wrote:
>
>
> A very interesting idea! You could bound with a lower resolution mesh if
> you use a slightly higher potential threshold.
>
> -Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote in message <37998295@news.povray.org>...
>
>The EU and its member states are independent. The USA cannot blackmail the
>EU or any of its member states. The economic power (superseding that of the
>USA) of the EU and independence from USA markets doesn't put the USA in a
>position to put up any pressure..the USA cannot afford a trade war with the
>EU as this would seriously damage growth in the USA and no president/party
>could survive it :-)
Yes, but just try convincing the politicians of that! :-)
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 24 Jul 1999 12:36:50 -0400, Nathan Kopp wrote:
>
>Ben Birdsey wrote:
>>
>> But let me toss in another suggestion that might short-circuit the critics
AND
>> keep the speed advantage. Let's compute the mesh and use it as a bounding
>> surface (i.e. we are 99.5% sure that the isosurface totally inside this mesh).
>> And, you could just render the mesh for test renders. This will totally reduce
>> the number wasted calculations, and keep the beauty of the isosurfaces at al
>> resolutions!
>
>A very interesting idea! You could bound with a lower resolution mesh if
>you use a slightly higher potential threshold.
f(x,y,z) = x^2+y^2+z^2-1
g(x,y,z) = 1-x^2-y^2-z^2
Both f and g are spheres. Both have unit radius if you use a threshold of
zero. If you use a higher threshold, f gets larger while g gets smaller.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
