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] pacbellnet> 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

On Tue, 6 Apr 1999 17:09:48 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:

>Maybe we can borrow gcc's code here -- it's all open source, right?

GCC is GPL.  GPL is not compatible with the POV license.  In fact,
the POV license isn't even technically open source.

>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.

Java is nearly as fast as compiled code if you have a JIT.
Neither system is interpreted, though; they're both p-code
systems, just like older Visual Basic stuff.  

>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?

I don't know which parts will be added, but a bunch of the
stuff in the superpatch will make it into version 3.5.

Post a reply to this message

On Tue, 6 Apr 1999 17:27:56 -0700, "Ray Gardener"
<ray### [at] daylongraphicscom> wrote:

>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.

There's nothing wrong with using POV for production work. The thing
they're trying to prevent is someone taking the POV renderer and using
it as the core of a commercial program.  It's sorta the same idea that
lies behind the GPL: this code was developed by lots of people over a
very long time, and many of the people involved donated their work for
the good of the community.  For that work to instead be used to line
the pockets of some unscrupulous person of corporation is anathema.

Now, I happen to think the GPL would do just as good a job of
protecting that investment as would the current license, except for
the clauses that prohibit specific parties from distributing POV.  But
it's not my program, so I don't get to decide that.

Post a reply to this message

Ray Gardener wrote:
> 
> Agreed, supporting all those CPUs is bothersome. But
> gcc does it, the templates are mature, and we can tweak

Does gcc support EVERY cpu?  The core of POV is supposted to be completely
platform independent (only the interface parts need to be changed to port
it to another system).  If someone invents a new CPU next week and they
make an ANSI C compiler for it, we could have a command-line version of
POV running on it in very little time.

Therefore any bytecode interpreter that is part of the core must also be
platform independent... JIT compilers could be extra for each system...
but the functionality would still exist for EVERY system.

-Nathan

Post a reply to this message

Ronald L. Parker wrote in message <370bb83f.25447192@news.povray.org>...
>
>There's nothing wrong with using POV for production work. The thing
>they're trying to prevent is someone taking the POV renderer and using
>it as the core of a commercial program.

Granted. But sooner or later, we have to face up
to this plug-in issue. I'd rather have the
POV-Team proactively taking the lead instead
of lots of people going around making patches
and other competing hacks to make it work.
If we sit around, POV will start fraying
at the edges.

That slope stuff is really neat, btw. I
whipped up this image while trying it out:

http://www.daylongraphics.com/products/leveller/tut/forest/final4.jpg

Post a reply to this message

Nathan Kopp wrote in message <370AE1F3.3DC4D6A3@Kopp.com>...
>Ray Gardener wrote:
>>
>> Agreed, supporting all those CPUs is bothersome. But
>> gcc does it, the templates are mature, and we can tweak
>
>Does gcc support EVERY cpu?  The core of POV is supposted to be completely
>platform independent ...
>
>Therefore any bytecode interpreter that is part of the core must also be
>platform independent... JIT compilers could be extra for each system...
>but the functionality would still exist for EVERY system.



If a JIT is truly fast enough (does anyone have benchmarks
from that JavaRays program?) then that would be great. But
if not... and let's face it, for all of fuss over JITs,
they haven't had any real impact on day-to-day computing.
When I see JITs used for commercial video games, then
I'll be impressed. And how much RAM did Sun say their JIT
needed? Tons and tons? Insane.

The irony is, that if a new instruction set appears, one
still needs to ultimately port something. For the same amount
of work, you may as well just port a native-code compiler.
The bytecode interpreter might be available, but I don't think anyone
would seriously use it. I'd sooner buy hardware supported
by a JIT instead of run bytecode (because hardware is now
so cheap these days). But if I'm doing that, I'll opt
for the hardware that's natively supported, and get even
more speed.

With raytracing, there's never a point where the
system is 'fast enough'. Even if gigahertz machines
were common, we'd still need every last bit of performance.
If the pics we're doing today render quickly, we'll
start doing more complex scenes. And then there's movies,
which need tons of frames, etc. It's not like accounting,
were there's only so much math a transaction can involve.

So Ron's saying gcc's code can't be used to improve POV.
Well, that sure strikes a blow for the open source
movement. What a collosally wasted opportunity.

Ray

Post a reply to this message

Ray Gardener wrote:
> 
> If a JIT is truly fast enough (does anyone have benchmarks
> from that JavaRays program?) then that would be great. But
> if not... and let's face it, for all of fuss over JITs,
> they haven't had any real impact on day-to-day computing.
> When I see JITs used for commercial video games, then
> I'll be impressed. And how much RAM did Sun say their JIT
> needed? Tons and tons? Insane.

Current Java JIT, as you indicate, is too slow and too much of a
resource hog.  I agree.

> With raytracing, there's never a point where the
> system is 'fast enough'. Even if gigahertz machines
> were common, we'd still need every last bit of performance.
> If the pics we're doing today render quickly, we'll
> start doing more complex scenes. And then there's movies,
> which need tons of frames, etc. It's not like accounting,
> were there's only so much math a transaction can involve.

I agree.  However, as you say in your other post, the plug-in issue
must be dealt with at some point.  So the question becomes, "what
format do the plug-ins take and how are they distributed?"

Binary plugins:
* very fast
* system-dependent
* must be recompiled for each system, which requires a the user to have
  access to development tools
* probably different program<->plugin interfaces on each system
  For example, a DLL-type system exists on some UNIX systems, but it
  works in a totally different way.  Now the core of POV is no longer
  system-independent.

Source/bytecode plugins (I consider these to be very similar):
* interpreted, very slow
* platform independent, provided interpreter is platform independent
* could be JIT compiled
* JIT compilers are still slow
* interpreter/JIT compiler would bloat the POV-Ray executable

> So Ron's saying gcc's code can't be used to improve POV.
> Well, that sure strikes a blow for the open source
> movement. What a collosally wasted opportunity.

The reason it can't be used is that if you use GPL source in your program,
your code must also be put under GPL.  And POV is not under GPL.

Somebody should design the following:  the "POV Plugin Dynamic Library",
or PPDL for short.  The development kit would consist of a modified GCC
which compiles POV shaders (or other plugins) to a PPDL format.  This
PPDL could include binary code for a variety of systems in the same
file.  The PPDL interface (meaning how POV talks to the plugin) would be
the same for all systems, keeping the core of POV system independent and
the part of this system embedded in POV would be developed independently
of GPL stuff and would therefore not be part of GPL.  A pov plugin
compiler could be made available for all systems that are supported by
GCC.  And maybe the PPDL specification would include the plugin source
in the PPDL file (all-in-one-package design) so that people could easily
add/remove binary sections.  (a PPDL file would have multiple sections:
one for the source and others for the binary parts)

Of course, binary plugins like this would be susceptible to trojans and
viruses.  :-(

Ambitious, huh?  Has anyone done anything like this before?

-Nathan

Post a reply to this message

On Wed, 7 Apr 1999 12:48:47 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>So Ron's saying gcc's code can't be used to improve POV.
>Well, that sure strikes a blow for the open source
>movement.

No it doesn't.  It strikes a blow for the non-open-source (i.e. POVLEGAL)
movement.

Post a reply to this message

Hey now...
Quake3arena will be based on a JIT compiler..
it will be using one binary for the server part, and one for client part
computing(not gfx).

It will be written in ansi C, pre-compiled into a binary form, then compiled at
runtime for each system, using the internal C processor in quake 3...
it will all be based on LCC.

Well, JIT in games, of course :-)


Ray Gardener wrote:
> 
> Nathan Kopp wrote in message <370AE1F3.3DC4D6A3@Kopp.com>...
> >Ray Gardener wrote:
> >>
> >> Agreed, supporting all those CPUs is bothersome. But
> >> gcc does it, the templates are mature, and we can tweak
> >
> >Does gcc support EVERY cpu?  The core of POV is supposted to be completely
> >platform independent ...
> >
> >Therefore any bytecode interpreter that is part of the core must also be
> >platform independent... JIT compilers could be extra for each system...
> >but the functionality would still exist for EVERY system.
> 
> If a JIT is truly fast enough (does anyone have benchmarks
> from that JavaRays program?) then that would be great. But
> if not... and let's face it, for all of fuss over JITs,
> they haven't had any real impact on day-to-day computing.
> When I see JITs used for commercial video games, then
> I'll be impressed. And how much RAM did Sun say their JIT
> needed? Tons and tons? Insane.
> 
> The irony is, that if a new instruction set appears, one
> still needs to ultimately port something. For the same amount
> of work, you may as well just port a native-code compiler.
> The bytecode interpreter might be available, but I don't think anyone
> would seriously use it. I'd sooner buy hardware supported
> by a JIT instead of run bytecode (because hardware is now
> so cheap these days). But if I'm doing that, I'll opt
> for the hardware that's natively supported, and get even
> more speed.
> 
> With raytracing, there's never a point where the
> system is 'fast enough'. Even if gigahertz machines
> were common, we'd still need every last bit of performance.
> If the pics we're doing today render quickly, we'll
> start doing more complex scenes. And then there's movies,
> which need tons of frames, etc. It's not like accounting,
> were there's only so much math a transaction can involve.
> 
> So Ron's saying gcc's code can't be used to improve POV.
> Well, that sure strikes a blow for the open source
> movement. What a collosally wasted opportunity.
> 
> Ray

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

On Wed, 07 Apr 1999 16:23:35 -0400, Nathan Kopp <Nat### [at] Koppcom> wrote:
>Somebody should design the following:  the "POV Plugin Dynamic Library",
>or PPDL for short.  The development kit would consist of a modified GCC
>which compiles POV shaders (or other plugins) to a PPDL format.  This
>PPDL could include binary code for a variety of systems in the same
>file.

Not much modification to GCC required, just a bunch of cross-compilers
and something that can read .o files and make ppdl files (a linker of 
sorts).

Who decides which systems will be supported?  Will we have binaries 
for M68K? (assuming for the moment that no system calls will be made,
so a Linux M68K binary is just like a Mac one is just like an
Amiga one.  Of course, that ignores the problem of calling conventions
and reserved registers.) How about Alpha?  Sparc?  MIPS?  What about 
all those other weird architectures Linux and GCC (and presumably 
POV-Ray) run on?  Who's going to test this thing?

Okay, so if I'm running a port of POV on my custom foo42 processor, I
probably have GCC ported to it and can compile my own binary chunk for
any plugins that come my way, but what if I give my foo42 build to my
buddy next door who has the same processor but zero technical expertise?
Where does he get a binary chunk for the nifty new plugin he just got?

>The PPDL interface (meaning how POV talks to the plugin) would be
>the same for all systems, keeping the core of POV system independent and
>the part of this system embedded in POV would be developed independently
>of GPL stuff and would therefore not be part of GPL.  

Okay, so I have this binary file with lots of different formats in it.
I've just allocated a block of memory and read the appropriate code 
into it, relocated addresses where necessary, and i'm ready to run it.
Now where did I put that library routine that lets me mark a data page 
(or pages) as executable?  I mean, I know how to do it under WinNT, but 
that's a Win32 API call.  I'm looking for something cross-platform.

Post a reply to this message

Ray Gardener wrote:

> That slope stuff is really neat, btw. I
> whipped up this image while trying it out:
> 
> http://www.daylongraphics.com/products/leveller/tut/forest/final4.jpg

 I'm impressed.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

>Nathan Kopp:

>Somebody should design the following:  the "POV Plugin Dynamic Library",
>or PPDL for short.  The development kit would consist of a modified GCC
>which compiles POV shaders (or other plugins) to a PPDL format.  This
>PPDL could include... [snip]

Sounds good to me. As least you're being
proactive and trying for a solution.

I suspect that most developers will opt to
build 'partial' plug-ins that only support
the two or three favorite platforms, but
that pretty much mirrors POV -- WinPOV
has the nicest GUI and latest builds, etc.


>Of course, binary plugins like this would be susceptible to trojans and
>viruses.  :-(


True, but that's always the case with
any binary, even builds of POV. We just
have to download from trusted sources
like we always do. If we mandate that
the source has to be provided, then
security freaks can always build their
own local binary of a plug-in.


>Ambitious, huh?  Has anyone done anything like this before?


Ambitious, yes. Original? I don't know.
But if the end goal is reached, you'll
get my vote for the Nobel Prize for
POV programming. Or the 'Most Judicious
Use of Plug-ins in a POV-Ray Script'
category at the Oscars. :)

Ray

Post a reply to this message

In article <370c283f.1@news.povray.org> , "Ray Gardener" 
<ray### [at] daylongraphicscom> wrote:

> I suspect that most developers will opt to
> build 'partial' plug-ins that only support
> the two or three favorite platforms, but
> that pretty much mirrors POV -- WinPOV
> has the nicest GUI and latest builds, etc.

"WinPOV has the nicest GUI and latest builds", aha (???)...
"only support the two or three [...] platforms", great idea (irony!)...


    Thorsten


PS: Did I miss the last ten years or so and it is 2009???  ;-)

Post a reply to this message

Spider wrote in message <370BC0F6.55C32441@bahnhof.se>...
>Hey now...
>Quake3arena will be based on a JIT compiler..
>it will be using one binary for the server part, and one for client part
>computing(not gfx).


Ooo... Quake on a JIT. Now I'll be able to
make detailed observations on the gameplay
to others.

"See that rocket? In ten seconds it will
hit that wall. But before it does, notice
the subtle use of rust and dirt used
to texture the fuselage..." :)

Ray

Post a reply to this message

Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
>
>  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.


Well, I was all set to add raytracing to Leveller,
but then I thought, the world doesn't need Yet
Another Renderer. Before I go down that road,
due dilegence requires that I look into seeing
what POV-Ray can do (or be made to do). Otherwise,
there's a danger of adding rendering features
specific to Leveller, and then it would have to
render all sorts of other primitives in order
to make full scenes work. And I'd have to constantly
keep upgrading the renderer to keep it current.
With a full-time staff, maybe, but not the way
things are now.

And people have a big investment in POV -- it's
better to leverage that. We're almost at the
point where $50-$100 gets you into some serious
kick-ass landscape modelling/rendering, without
being overly difficult for the average user.
When the Superpatch is integrated into POV 3.5,
and Leveller starts automating the script
generation for the new texture options more,
I think we're going to see some amazing stuff,
without burning me out production-wise. Or
someone else could automate the scripts, too.

Ray

Post a reply to this message

>"WinPOV has the nicest GUI and latest builds", aha (???)...
>"only support the two or three [...] platforms", great idea (irony!)...


It is ironic, yes. But I think the idea behind
having stringent multi-platform support is not
so that all those platforms have the software,
but that if someone wants to do the port, it's
nice to know that they have that option at
any time, and that the process won't involve
major gnashing of teeth. It's more a question of keeping
the options open than of actual availability.

Ray

Post a reply to this message

On Wed, 7 Apr 1999 22:18:22 -0700, Ray Gardener <ray### [at] daylongraphicscom> wrote:
>>"WinPOV has the nicest GUI and latest builds", aha (???)...
>>"only support the two or three [...] platforms", great idea (irony!)...
>
>
>It is ironic, yes. But I think the idea behind
>having stringent multi-platform support is not
>so that all those platforms have the software,
[...]

You seem to have missed the point, Ray.  Thorsten was obliquely commenting
that the Mac has a nicer GUI, and both Mac and DOS usually have the latest 
builds before Windows.  For a current illustration, go get the 3.1e source 
for DOS.  Now go get the 3.1e source for Windows.

Post a reply to this message

Ron Parker wrote:
> 
> Okay, so I have this binary file with lots of different formats in it.
> I've just allocated a block of memory and read the appropriate code
> into it, relocated addresses where necessary, and i'm ready to run it.
> Now where did I put that library routine that lets me mark a data page
> (or pages) as executable?  I mean, I know how to do it under WinNT, but
> that's a Win32 API call.  I'm looking for something cross-platform.

Ok, so there are a lot of issues to be worked out.  But I don't think it
would be impossible (just difficult maybe).

But if marking the code to be executable is the only non-cross-platform
thing, then I think that would be acceptable.  Unfortunately, I think
that there will be more complicated issues.

-Nathan

Post a reply to this message

On Thu, 08 Apr 1999 09:37:20 -0400, Nathan Kopp <Nat### [at] Koppcom> wrote:
>Ron Parker wrote:
>> 
>> Okay, so I have this binary file with lots of different formats in it.
>> I've just allocated a block of memory and read the appropriate code
>> into it, relocated addresses where necessary, and i'm ready to run it.
>> Now where did I put that library routine that lets me mark a data page
>> (or pages) as executable?  I mean, I know how to do it under WinNT, but
>> that's a Win32 API call.  I'm looking for something cross-platform.
>
>Ok, so there are a lot of issues to be worked out.  But I don't think it
>would be impossible (just difficult maybe).

Agreed.  I still think it's a good idea.

>But if marking the code to be executable is the only non-cross-platform
>thing, then I think that would be acceptable.  Unfortunately, I think
>that there will be more complicated issues.

Probably.  Still, it's an idea that I've tossed around myself.  Well, not
the fat-binary part of it, but the 'dynamic loading on platforms that
don't support it' part.  Maybe when the superpatch is done (ha!) I'll take 
some time to do a proof-of-concept for the platforms I have access to (which 
are unfortunately both X86 platforms, unless you count that poor old junker 
Amiga in the corner, the one that sometimes boots.)  I'd still be interested
in seeing (A) how much code bloat it would really add to integrate Kaffe with
POV, and (B) how much slower a pattern written in Java would be than the 
equivalent pattern patched directly into POV.  Function-based textures in
the isosurface patch aren't too slow, and they're not compiled (unless you
add a DLL.)

Post a reply to this message

<No Comment>

Post a reply to this message

In article <370cb1b6.0@news.povray.org> , par### [at] my-dejanewscom (Ron 
Parker) wrote:
>>"WinPOV has the nicest GUI and latest builds", aha (???)...
>
> You seem to have missed the point, Ray.  Thorsten was obliquely commenting
> that the Mac has a nicer GUI, and both Mac and DOS usually have the latest
> builds before Windows.  For a current illustration, go get the 3.1e source
> for DOS.  Now go get the 3.1e source for Windows.

Yes, you got my first point :-)


    Thorsten

Post a reply to this message

Ron Parker wrote in message <370cb1b6.0@news.povray.org>...
>You seem to have missed the point, Ray.  Thorsten was obliquely commenting
>that the Mac has a nicer GUI, and both Mac and DOS usually have the latest
>builds before Windows.  For a current illustration, go get the 3.1e source
>for DOS.  Now go get the 3.1e source for Windows.

I stand corrected. It's been my impression that
WinPOV was generally better supported than LinuxPOV,
and I tend to subconsciously lump all other
OSes into the minority group with Linux.

Ray

Post a reply to this message

Ray Gardener wrote:
> 
> Ken wrote in message <37097246.CEB5F0E3@pacbell.net>...
> >
> >  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.
> 
> Well, I was all set to add raytracing to Leveller,
> but then I thought, the world doesn't need Yet
> Another Renderer. Before I go down that road,
> due dilegence requires that I look into seeing
> what POV-Ray can do (or be made to do). Otherwise,
> there's a danger of adding rendering features
> specific to Leveller, and then it would have to
> render all sorts of other primitives in order
> to make full scenes work. And I'd have to constantly
> keep upgrading the renderer to keep it current.
> With a full-time staff, maybe, but not the way
> things are now.
> 
> And people have a big investment in POV -- it's
> better to leverage that. We're almost at the
> point where $50-$100 gets you into some serious
> kick-ass landscape modelling/rendering, without
> being overly difficult for the average user.
> When the Superpatch is integrated into POV 3.5,
> and Leveller starts automating the script
> generation for the new texture options more,
> I think we're going to see some amazing stuff,
> without burning me out production-wise. Or
> someone else could automate the scripts, too.
> 
> Ray

Hi Ray,

  I really had not intended to imply that Leveller graudate to a fully
integrated rendering package. The section you quoted above was a poorly
worded suggestion of options available to your current design challenge.
  The UV mapping function takes u and v coordinates and uses them to map
a texture to that location. Since Leveller knows the height value for
every pixel in the image it produces if should be possible to extract
that data and write it to the format used in the UV patch. This would
allow you very precise control of texture placement on any surface of
the topography independent of slope or height. How one would control
color, area selection, and optimization is left to the programmer to
figure out. I was mearly helping you explore the possiblities available
with currently available Pov processes and related software.

  It may even be a poor suggetion but I thought I should at least
clarify the rational for having made the suggestion in the first place.

Regards,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote in message <370CF87F.D0C5D314@pacbell.net>...
>
>  I really had not intended to imply that Leveller graudate to a fully
>integrated rendering package. The section you quoted above was a poorly
>worded suggestion of options available to your current design challenge.

>
> [useful stuff snipped]

Understood. It's just that for every newsgroup poster,
there's way more lurkers, and I figured it would be
good timing to explain how the vision thing was working
out. A lot of users desire improved rendering, and
this was a handy way to let them know what's being
planned, and the rationale behind it.

Hopefully I can start doing IRTC entries in time
for Leveller's first birthday (May 1/99, or close to that).
:)

Ray

Post a reply to this message