 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I've been hacking Windows POV-Ray 3.x to support
procedural texturing (to make heightfields
render terrain better). What I'd like
to know is, has anyone done this or is
already doing it? I'd just like to avoid
duplication of effort.
The procedural textures would be called
via a DLL system. Not binary portable,
I know, but I'm willing to live with it
to get better terrain.
I realize that POV's texturing features
are already very good, but I'm after
more advanced stuff that really insists
upon the procedural route.
Thanks,
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ray Gardener wrote:
>
> Hello,
>
> I've been hacking Windows POV-Ray 3.x to support
> procedural texturing (to make heightfields
> render terrain better). What I'd like
> to know is, has anyone done this or is
> already doing it? I'd just like to avoid
> duplication of effort.
>
> The procedural textures would be called
> via a DLL system. Not binary portable,
> I know, but I'm willing to live with it
> to get better terrain.
>
> I realize that POV's texturing features
> are already very good, but I'm after
> more advanced stuff that really insists
> upon the procedural route.
>
> Thanks,
> Ray
The photon patch by Nathan Kopp has a uv texturing scheme that is showing
some serious promise. You seem to have pretty good control of what is
happening where and at what level in Leveller and the two might find some
sort of harmonious exsistance.
Take a look at Nathan's Photon Patch page at:
http://nathan.kopp.com/patched.htm
I'm not sure what the exact wording is for the proceedure but the super patch
maintained by Ron Parker has a slope dependent texture routine that I have
seen used with HF's ( ISO surfaces ?). It is very promising. The couple of
images I have seen where it was used with HF's shows the limitations with the
official build and the power it adds to texturing uneven surfaces like terrain.
Ron can tell you more about it's capabilities than I can.
You can also download the Current docs for the Super Patch at twysted.net
in the patch station as well as downloading the most recent build.
You might also look at R. Suzuki's page. He just upgraded his official version
of the IsoSurface patched version of Pov and is certainly one of the most informed
on the subject. He made an announcement this week in this group and you can find
a link to his page along with his meassage.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 05 Apr 1999 19:32:38 -0700, Ken <tyl### [at] pacbell net> wrote:
> I'm not sure what the exact wording is for the proceedure but the super patch
>maintained by Ron Parker has a slope dependent texture routine that I have
>seen used with HF's ( ISO surfaces ?). It is very promising. The couple of
>images I have seen where it was used with HF's shows the limitations with the
>official build and the power it adds to texturing uneven surfaces like terrain.
>Ron can tell you more about it's capabilities than I can.
I can't tell you that much more, as it's not my patch either. The
original authors are lurking about here somewhere, no doubt. But the
documentation is fairly complete. Also in the superpatch and
concerning textures are the function-based textures from the
isosurface patch, so you can make the color (pigment, texture,
anything mappable) at a particular point be an arbitrary function of
x, y, and z. Currently, that's as close to a programmable texture as
you're likely to get. The new superpatch will include some new warps
that might help as well, plus the ability to calculate isosurfaces of
procedural pigments. That's just on hold until I get the docs from my
doc guy. :)
The main problem with a patch utilizing DLLs is that if it's based on
3.1x code, it may not be distributed due to the new terms in POVLegal.
The isosurface patch was sorta grandfathered on that clause, but it is
my understanding that when it's part of the official 3.5 it will no
longer support DLLs, either. Quoting Chris Young's "State of the
Renderer"[1] address from late December:
For example cross-platform portability is a major design priority
and the iso-surface patch makes use of DLLs that are not portable.
We will likely eliminate that part of the patch.
As a part of the superpatch, the DLL support is on shaky ground (but
legal, because I have written permission of a sort to distribute it
for the time being) and it could be axed at any time.
I have also been toying with the idea of "plugins" for POV, for both
textures and primitives, for almost a year now, and you can even find
some serious posts from me about it in cgrr if you go back far enough.
but that provision in POVLegal has kept me from doing anything
serious. My current fantasy involves using JNI to make POV talk to
plugins written in Java, now that I've managed to locate JVMs that run
on all platforms officially supported by POV. The idea is, if you
have a plugin that works on your Windows machine, you just put it
online and if I download it to my Linux machine it'll just work.
Since the plugins are just math and other boring stuff, they wouldn't
run afoul of any of the usual "write once debug everywhere" problems
Java has. And since the JVM already handles dynamic linking, it's
taken care of on systems that don't directly support it (like DOS.)
You also benefit from whatever JIT compiler might be available for
your system. Again, though, any work of this sort couldn't be
distributed under the terms of the current POVLegal, unless you
succeeded in getting it into an official version, and the POV-Team has
already weighed in fairly negatively on the subject of plugins, as
well as on the subject of Java. Quoting the same post[1]
again:
As I mentioned earlier, we originally planned that our next
release would be a major rewrite in C++ however we had lots of
input from users and team members that a compiled Java rewrite
might be a good alternative. In the 18 months since that debate,
Java has not fulfilled its promise to unite the world in the
peaceful harmony of a single, portable language. The whole
industry (not just Microsoft) is doing things to ruin Java.
Enough politics... Java is out.
And later in the same post:
We've had many requests for the ability to make plug-ins or
DLL type capability. Although the vast majority of our users run
Windows, we will not be doing anything to hurt the cross-platform
portability of the program. Not all operating systems have DLL
capability and even if they did, you'd have to re-compile the DLL
for every platform.
[1] http://www.dejanews.com/getdoc.xp?AN=427272205
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ronald L. Parker wrote:
<lots of good stuff clipped>
>
> your system. Again, though, any work of this sort couldn't be
> distributed under the terms of the current POVLegal, unless you
> succeeded in getting it into an official version, and the POV-Team has
> already weighed in fairly negatively on the subject of plugins, as
> well as on the subject of Java.
The problem with DLL plugins is that they aren't platform independent.
The problem with java is that it is changing too rapidly... no real
standard that is guaranteed to still be around next year (or month, for
that matter).
Also, adding a Java VM to POV could bloat it quite a bit.
I don't think the POV-Team is against the concept of plugins... I just
think that a top priority is platform independence, and if plugins don't
mix well with that, then they are out.
Overall, I do think we need kind of plug-in ability, though.
Unfortunately, I don't have a solution.
-Nathan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
>
> The photon patch by Nathan Kopp has a uv texturing scheme that is showing
>some serious promise. You seem to have pretty good control of what is
>happening where and at what level in Leveller and the two might find some
>sort of harmonious exsistance.
>
>Take a look at Nathan's Photon Patch page at:
>
>http://nathan.kopp.com/patched.htm
>
>
Thanks, I'll take a look at that and at SuperPatch
as well.
In regards to Ron's DLL comments, I agree that
portability is important. I don't know why
there would be a licencing issue with DLLs
per se -- if developers provide the source code
to their DLLs, just like they do for patches,
then what's the problem? In fact, I was going
to do my changes as a patch, but wanted to
use DLLs just to avoid bloating pvengine.exe.
Granted, people could abuse the DLL system,
and start distributing binaries only. I can
see that being at cross purposes to POV's
normal distribution.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote in message <37098AFE.EF824E2D@Kopp.com>...
>
>Overall, I do think we need kind of plug-in ability, though.
>Unfortunately, I don't have a solution.
Why not just add a simple C compiler to
POV's parser? The technology's been
around for eons.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 6 Apr 1999 10:11:40 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
>>
>> The photon patch by Nathan Kopp has a uv texturing scheme that is showing
>>some serious promise. You seem to have pretty good control of what is
>>happening where and at what level in Leveller and the two might find some
>>sort of harmonious exsistance.
>>
>>Take a look at Nathan's Photon Patch page at:
>>
>>http://nathan.kopp.com/patched.htm
>>
>>
>Thanks, I'll take a look at that and at SuperPatch
>as well.
>
>In regards to Ron's DLL comments, I agree that
>portability is important. I don't know why
>there would be a licencing issue with DLLs
>per se
Previous to version 3.1, there were no licensing issues with DLLs. With
version 3.1, the Team added a clause to POVLEGAL forbidding adding
additional APIs to the code. The primary motivation, as I understand it,
was as a preemptive strike against those who would embed the POV code in
an ActiveX control or OLE server or whatnot. The Team doesn't want to
see POV being integrated too tightly with commercial code, to the extent
that it's not obvious to the end user that it's POV doing the work. The
restriction is intended to keep that from happening, but the end result
is that it keeps things like plugins from happening too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 6 Apr 1999 10:16:44 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>
>Nathan Kopp wrote in message <37098AFE.EF824E2D@Kopp.com>...
>
>>
>>Overall, I do think we need kind of plug-in ability, though.
>>Unfortunately, I don't have a solution.
>
>
>Why not just add a simple C compiler to
>POV's parser? The technology's been
>around for eons.
What would it compile to? Bytecode? Machine language? If to machine
language, you'll need some kind of loader to get the code in a place where
it's executable, and you'd have to be able to generate code for any processor
POV is to run on - including x86, 680x0, Sparc, Alpha, and PPC architectures.
If to bytecode, why not just integrate the Java VM and get the JIT stuff too?
Now those who know me know that I'm not a Java zealot. In fact, I've come out
against Java many times in the past few years. But I think this is exactly
what Java was made to do.
I originally thought about embedding a Perl interpreter for the purposes of
doing programmable shaders and primitives. The process for doing so is
well-documented, the nature of Perl sorta requires that source to the plugin
be available (though the nature of Perl also allows for it to be completely
unreadable), and it compiles to bytecode and runs pretty quickly. I don't
know offhand whether the Artistic License is compatible with POVLEGAL or not,
but that's easy enough to check. I don't know whether such a thing would
fall under the "new api" clause, though, so you'd still have to run it by
the POV-Team before distributing it. There is some overhead involved - the
Perl DLL on win32 is about half a meg. Still, that's probably pretty small
compared to a Java VM.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote in message <370a4845.0@news.povray.org>...
>On Tue, 6 Apr 1999 10:16:44 -0700, Ray Gardener <ray### [at] daylongraphicscom>
wrote:
>>
>>Why not just add a simple C compiler to
>>POV's parser? The technology's been
>>around for eons.
>
>What would it compile to? Bytecode? Machine language? If to machine
>language, you'll need some kind of loader to get the code in a place where
>it's executable, and... [snip]
Agreed, supporting all those CPUs is bothersome. But
gcc does it, the templates are mature, and we can tweak
for MMX, 3DNow and the PPC's multiply+add and the like. Besides,
it's not like there are new instruction sets coming out every week.
Maybe we can borrow gcc's code here -- it's all open source, right?
As for the loader, just compile down into a temp DLL (if on Windows)
and then use LoadLibrary() to run it.
As for Java, Perl, and any other interpretation system:
I have to pass. No interpreter is fast enough; I need
every last machine cycle available, when you consider that
the code may need to be called for every pixel on the
rendered image.
Read the stuff about 'slope' in the SuperPatch docs.
Pretty heavy; it may do everything I need. So when
does this great stuff get merged into the offical POV?
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>...The Team doesn't want to
>see POV being integrated too tightly with commercial code, to the extent
>that it's not obvious to the end user that it's POV doing the work. The
>restriction is intended to keep that from happening, but the end result
>is that it keeps things like plugins from happening too.
I can understand that. With the latest round of work
being done on POV-Ray, however, it's becoming obvious
that POV-Ray is being taken seriously and people are
trying to make it do very serious work, and likewise
the POV-Team should start taking that into account
(if they haven't already).
Good programs never stagnate; they either get better
or get eclipsed by something else. POV-Ray is maturing
into what will (hopefully) be true production class,
and that's a different environment than a bunch of
people writing raytracing code for fun. You don't
see Linus Torvalds getting upset when some commercial
enterprise makes money off Linux, because he's
happy just to have created it, regardless of
what happens after. He'd be upset if someone were to
wind up owning Linux, but the protections have
already been put into place to prevent that, I think.
Ray
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
