 |
|
|
|
|
|
| |
| |
|
|
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] gmx de>
> 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
|
|
| |
| |
|
|
From: Warp
Subject: Re: Can someone patch POV so that you can output an isosurface as a wire fr=
Date: 9 Nov 2002 19:07:04
Message: <3dcda328@news.povray.org>
|
|
|
| |
| |
|
|
normdoering <nor### [at] yahoocom> wrote:
>> Windows has dll's and *nices have .so's etc.
> I don't know anything about "nices have .so's etc."
"*nices" is a kind of geek-word meaning "unix operating systems".
In them dynamically linkable libraries use the .so format (which is
different from the .dll format used in windows, even though for the
exact same purpose).
> It seems code for plugins could be as platform independent as the POV-ray
> code...
The problem is not the plugin code. The problem is how POV-Ray will read
this plugin binary and link it dynamically to itself. This can't be done in a
platform-independent way.
Even if a plugin system was implemented, it would certainly need serious
and thorough changes to the POV-Ray code. Probably too much for a simple
patch.
> Make headers and include files for the various platforms available like you
> make different compilations of POV-ray available.
That's not enough for a plugin system. It's not only the headers, you need
also some actual C++ code to handle the plugins. This code can't be done
in a portable way.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: Can someone patch POV so that you can output an isosurface as a wire fr=
Date: 9 Nov 2002 19:09:14
Message: <3dcda3a9@news.povray.org>
|
|
|
| |
| |
|
|
normdoering <nor### [at] yahoocom> wrote:
> Meaning the platform independent philosophy you guys have is standing in the
> way of writing faster and more efficient program.
POV-Ray is not slower and less efficient because it does not support
plugins. It simply does not support plugins, that's it.
You can try to add plugin support for POV-Ray if you want. Good luck. ;)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
