|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dcc3148@news.povray.org>, Simon Adameit <gom### [at] gmxde>
wrote:
> Do you consider this to be some kind of volumetric rendering?
>
> http://www.graphics.stanford.edu/~henrik/papers/psp/
Interesting...somewhat like a blob or isosurface, but not. No more
foolproof than converting to a mesh, and probably prone to other errors,
but probably useful for data from real world objects. It has
restrictions that seem to make the kind of point data being discussed
here useless. It needs a lot of points, and probably doesn't do well
with thin areas (where the thickness of the object is close to or lower
than the distance between points on the same "side", so the nearest
point can be on the opposite side of the object). The paper says it is
for extremely high resolution models, especially where triangles are
smaller than pixels, and a mesh doesn't give any real benefit.
It isn't what I meant by volumetric rendering, but it does require
sampling a volume...it seems to do "ray marching", stepping along the
ray until point density goes above a threshold, then using the points
within a certain distance of that location (though the abstract says
within a distance to the ray, which doesn't seem to make sense) to
figure out an approximation of the real distance.
That is a very interesting paper, I'm going to have a try at
implementing that object...need to get some papers of my own written
first, though. Homework...bleh.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>normdoering <nor### [at] yahoocom> wrote:
>> Has anyone worked with this feature and webpublished, written similar
>> macros? More examples would be a help.
>
> Yes, there are some famous macro sets made by people which handle
>meshes. For example the surface subdivision suite (by John VanSickle),
>which allows automatically making a mesh more detailed than the original,
>as well as the POV-Ray compressed mesh handler macros (by Chris Colefax),
>which allow you to make a wide variety of things to meshes, such as
>deformations, morphing, hair-growing, etc.
>
> They can be found at these places:
>
>http://enphilistor.users4.50megs.com/sss.htm
>http://www.geocities.com/ccolefax/pcm.html
>
> (Note that due to the fact that (currently) you can't extract information
>from a mesh inside POV-Ray, the meshes have to be converted to a specialized
>format called PCM, which these macros can handle. The converter can be
>found at the second link above.)
>
>#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
>-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
>
Thanks for your help. I was familiar with the compressed mesh, but the
surface subdivision stuff by John VanSickle is new to me. It sounds like
one I could learn a lot from.
If you're interested I'm going to move this HF_ macro talk to either
tutorials or advanced user area (maybe they need a special group for macros
here?) when I really get kicking on my macro writing (no doubt it will give
me lots of questions) and I'll share what I'm working on.
As noted before, this is no longer about patching. Only patching I want now
is a way to speed of the process... parsing takes forever when you use a
lot of resolution on the mesh.
Maybe complining macros so they run faster? I'm sure that's been discussed
before.
--normdoering
Post a reply to this message
|
|
| |
| |
|
|
From: Simon Adameit
Subject: Re: Can someone patch POV so that you can output an isosurface as a wire fr=
Date: 9 Nov 2002 04:55:06
Message: <3dccdb7a@news.povray.org>
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
> In article <3dcc3148@news.povray.org>, Simon Adameit <gom### [at] gmxde>
> wrote:
> It isn't what I meant by volumetric rendering, but it does require
> sampling a volume...it seems to do "ray marching", stepping along the
> ray until point density goes above a threshold, then using the points
> within a certain distance of that location (though the abstract says
> within a distance to the ray, which doesn't seem to make sense) to
> figure out an approximation of the real distance.
They dont use ray marching but instead they put a disc at each point and
intersect the ray with these to see if an intersection occured. They
only consider points within a certain distance to the ray. If there is
an intersection they interpolate it from all the points within a short
cylinder that is started at that location.
> That is a very interesting paper, I'm going to have a try at
> implementing that object...need to get some papers of my own written
> first, though. Homework...bleh.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3dccd13b195c50e45c65a5ba0@news.povray.org>,
"normdoering" <nor### [at] yahoocom> wrote:
> If you're interested I'm going to move this HF_ macro talk to either
> tutorials or advanced user area
Not one of the tutorials groups, those are reserved for tutorials.
That's why they have that word int their names.
> (maybe they need a special group for macros here?)
No. That's what the *.newusers and *.advanced-users groups are for.
> Maybe complining macros so they run faster? I'm sure that's been discussed
> before.
Yes, it has. The web interface makes a great search interface, look for
discussions on the POV language. Compiling to byte code to run on a VM,
like Java or POV functions do now, has been discussed for a while. It
isn't something that could just be added to 3.5 though.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3dccdb7a@news.povray.org>, Simon Adameit <gom### [at] gmxde>
wrote:
> They dont use ray marching but instead they put a disc at each point and
> intersect the ray with these to see if an intersection occured.
Yes, I found that out when I actually looked at the paper. The abstract
was a bit misleading...it doesn't rely on the point density in this way.
> They only consider points within a certain distance to the ray. If
> there is an intersection they interpolate it from all the points
> within a short cylinder that is started at that location.
In other words, within a certain distance of a short segment of the ray,
not the whole ray. Though it looks like they are also thinking about
using a cylinder based on the first disc hit, that would allow them to
precalculate the points to consider.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
....
>> (maybe they need a special group for macros here?)
>
>No. That's what the *.newusers and *.advanced-users groups are for.
Fine, I think I'll used advanced-users... if that's alright with you.
>> Maybe complining macros so they run faster? I'm sure that's been discussed
>> before.
>
>Yes, it has. The web interface makes a great search interface, look for
>discussions on the POV language. Compiling to byte code to run on a VM,
>like Java or POV functions do now, has been discussed for a while. It
>isn't something that could just be added to 3.5 though.
How about "plugins?" A lot of programs, like Corel Draw, have programs you
can plug in to Corel to do extra fancy stuff to pictures. I think they're
..DLLs...? You write them in basic or C++ or pascal but they would do the
work of a macro (and more since they could read binary code) and do it
faster. That way you could avoid the work of turning POV into a compiler.
In POV you'd call them from the Scene Description File. Wouldn't that be a
necessary stepping stone towards compiling macros?
--normdoering
Post a reply to this message
|
|
| |
| |
|
|
From: Johannes Dahlstrom
Subject: Re: Can someone patch POV so that you can output an isosurface as a wire fr=
Date: 9 Nov 2002 14:14:34
Message: <3dcd5e9a@news.povray.org>
|
|
|
| |
| |
|
|
normdoering wrote:
> How about "plugins?" A lot of programs, like Corel Draw, have programs you
> can plug in to Corel to do extra fancy stuff to pictures. I think they're
> ..DLLs...?
It has been proposed before... the big problem with plugins is that there's
no platform independent way to implement them. Windows has dll's and *nices
have .so's etc. Plugins compiled on one platform wouldn't work on other.
Besides, if they would be distributed in compiled form, other users
couldn't modify them to suit their needs. Making their sources availabele
wouldn't help much, because one would need a separate compiler to use them.
IMO it's much better to have a dedicated, powerful language to do this kind
of stuff.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.3dcd54f1195c50e47efeba520@news.povray.org>,
"normdoering" <nor### [at] yahoocom> wrote:
> How about "plugins?" A lot of programs, like Corel Draw, have programs you
> can plug in to Corel to do extra fancy stuff to pictures. I think they're
> ..DLLs...? You write them in basic or C++ or pascal but they would do the
> work of a macro (and more since they could read binary code) and do it
> faster. That way you could avoid the work of turning POV into a compiler.
> In POV you'd call them from the Scene Description File. Wouldn't that be a
> necessary stepping stone towards compiling macros?
That's been discussed as well, often in the same threads (you could also
do a search for "plugin"). You can't do it in a platform independant
way, and it introduces other problems, like having to make sure people
have a plugin before they can render a scene and having to recompile
plugins as well as the program for different platforms. It would be
useful, but the cons outweigh the pros at this time.
Another possibility that has been discussed would be to use compiled
byte-code for a VM. This would be platform independant, but wouldn't
really have any advantages over an include file that is compiled to byte
codes when the scene is rendered. It would also be slower than native
compiled code.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Johannes Dahlstrom wrote:
>normdoering wrote:
>
>> How about "plugins?" A lot of programs, like Corel Draw, have programs you
>> can plug in to Corel to do extra fancy stuff to pictures. I think they're
>> ..DLLs...?
>
>
>It has been proposed before... the big problem with plugins is that there's
>no platform independent way to implement them.
True. That only means you can compile the same C code on different compilers
for different machines. And can you really do that without changing the
code in some header or include file somewhere?
> Windows has dll's and *nices have .so's etc.
I don't know anything about "nices have .so's etc."
> Plugins compiled on one platform wouldn't work on other.
So? Versions of POV-ray compiled for Windows don't work on Apples.
It seems code for plugins could be as platform independent as the POV-ray
code... unless there's something I'm missing. It may be just a matter of
changing a few header and include files to make the same code work on
various platforms, same as POV-ray.
>Besides, if they would be distributed in compiled form, other users
>couldn't modify them to suit their needs.
True. That's the price of speed. But I don't want be able to modify
everything, as a user ... besides, I did say plugins would be an easy
stepping stone toward compiled macros. Once you could do that the plugins
would become obsolete. Doing a plugin version gets you part way to compiled
macros that are platform independent because the compiled macro would
behave just like a plugin.
> Making their sources availabele wouldn't help much, because one would
> need a separate compiler to use them.
Make headers and include files for the various platforms available like you
make different compilations of POV-ray available.
>IMO it's much better to have a dedicated, powerful language to do this kind
>of stuff.
True. But that's going to be harder to do because you have to write a
compiler into POV-ray and doing plugins would take care of one part of the
work, interfacing with a compiled program, and let users find the bugs
before you did the more complex task of actually writing a compiler.
You could simply implement plugins quicker than you could make macros
compile.
--normdoering
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff wrote:
>In article <web.3dcd54f1195c50e47efeba520[at]news.povray.org>,
> "normdoering" <nor### [at] yahoocom> wrote:
>
>> How about "plugins?" A lot of programs, like Corel Draw, have programs you
>> can plug in to Corel to do extra fancy stuff to pictures. I think they're
>> ..DLLs...? You write them in basic or C++ or pascal but they would do the
>> work of a macro (and more since they could read binary code) and do it
>> faster. That way you could avoid the work of turning POV into a compiler.
>> In POV you'd call them from the Scene Description File. Wouldn't that be a
>> necessary stepping stone towards compiling macros?
>
>That's been discussed as well, often in the same threads (you could also
>do a search for "plugin"). You can't do it in a platform independant
>way, and it introduces other problems, like having to make sure people
>have a plugin before they can render a scene and having to recompile
>plugins as well as the program for different platforms. It would be
>useful, but the cons outweigh the pros at this time.
>Another possibility that has been discussed would be to use compiled
>byte-code for a VM. This would be platform independant, but wouldn't
>really have any advantages over an include file that is compiled to byte
>codes when the scene is rendered. It would also be slower than native
>compiled code.
>
>Christopher James Huff <cja### [at] earthlinknet>
>http://home.earthlink.net/~cjameshuff/
>POV-Ray TAG: chr### [at] tagpovrayorg
>http://tag.povray.org/
>
Meaning the platform independent philosophy you guys have is standing in the
way of writing faster and more efficient program.
normdoering
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|