John VanSickle <van### [at] erolscom> wrote:
: This could be seen as an alternative form of UV mapping, I suppose.

  I think that it's not an alternative to UV-mapping, but actually you
really were talking about UV-mapping.
  Does the uv-mapping patch support uv-mapping for procedural textures or
only for bitmaps?

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

The uv patch supports both bimaps and procedural textures.

Margus

Nieminen Mika wrote:
> 
> John VanSickle <van### [at] erolscom> wrote:
> : This could be seen as an alternative form of UV mapping, I suppose.
> 
>   I think that it's not an alternative to UV-mapping, but actually you
> really were talking about UV-mapping.
>   Does the uv-mapping patch support uv-mapping for procedural textures or
> only for bitmaps?
> 
> --
> main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
> *_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp. -*/

Post a reply to this message

Margus Ramst wrote in message <36BEE54F.1099D40A@peak.edu.ee>...
>The uv patch supports both bimaps and procedural textures.
>
>Margus
>
>Nieminen Mika wrote:
>>
>> John VanSickle <van### [at] erolscom> wrote:
>> : This could be seen as an alternative form of UV mapping, I suppose.
>>
>>   I think that it's not an alternative to UV-mapping, but actually you
>> really were talking about UV-mapping.
>>   Does the uv-mapping patch support uv-mapping for procedural textures or
>> only for bitmaps?



Grr...  I know this have been brought up before, but why can't POV accept
dlls to add new features to it, like Moray? Yes, I know they're platform
specific - but it would be great if this ability could be added even just to
the Windows version.  Yeah, sure - I suppose they'd be quite a technical
problems (like what sort of procedures would be required in the first place
to write the dlls) but I can only hope ;)

From someone that prefers to only use the official POV binaries, it's
annoying to see so many great ideas/features only available from
"home-built" patched versions. :(


Just my 2 pence,

Matt

Post a reply to this message

On Mon, 8 Feb 1999 19:22:00 -0000, Matthew Bennett 
	<ben### [at] btinternetcom> wrote:
>Grr...  I know this have been brought up before, but why can't POV accept
>dlls to add new features to it, like Moray? Yes, I know they're platform
>specific - but it would be great if this ability could be added even just to
>the Windows version.  Yeah, sure - I suppose they'd be quite a technical
>problems (like what sort of procedures would be required in the first place
>to write the dlls) but I can only hope ;)

I considered doing this at one point, and I even sent a (rough) 
proposal to the POV Team about it, since doing anything with it 
would require a variance to POVLEGAL.  Last I heard, they were 
going to revisit it after 3.1 was out the door.  Obviously 3.1 
has shipped, but since I don't have time to actually do the project 
right now anyway, I haven't bothered trying to shepherd the proposal 
back onto their schedules.  The cross-platform stuff isn't as bad 
as it looks - most modern operating systems support dynamic linking 
in one form or another, and the rest (i.e. DOS) would still benefit 
from the greater organization inherent in the plugin model.  Still, 
Chris Young has indicated that dynamic loading is not something the 
Team wants to think about, as evidenced by the likely removal of 
"function library" support from the isosurface patch if and when it
is made official.

You should know, though, that a lot of the less simple patches,
including the UV mapping patch, would be difficult to fit into
any kind of simple plugin model anyway.

>From someone that prefers to only use the official POV binaries, it's
>annoying to see so many great ideas/features only available from
>"home-built" patched versions. :(

Chris Young has said that they're seriously looking at all of the 
available patches with an eye toward including some of them in 
version 3.5. We'll all just have to sit back and see what happens.

Post a reply to this message

"Matthew Bennett" <ben### [at] btinternetcom> wrote:

>Grr...  I know this have been brought up before, but why can't POV accept
>dlls to add new features to it, like Moray? Yes, I know they're platform
>specific - but it would be great if this ability could be added even just to
>the Windows version.  Yeah, sure - I suppose they'd be quite a technical

it's not just technical. just imagine what it would be like if we started to
have scene files floating around that depended on a particular mod being
loaded. it'd fragment POV's standard, work-on-any-platform scene language
into a bunch of platform-specific dialects.

Post a reply to this message

I have to agree, I think the team has made a good effort in keeping it
standradized. As for that, What is it that _must_ be in a separate dll,
that can't be linked in in a header file ?


//Spider

Post a reply to this message

How would this be different than having to use say the SuperPatch
version to render something?  I'm not really seeing the distinction.

Steve


"povray.org admin team" wrote:
> 
> "Matthew Bennett" <ben### [at] btinternetcom> wrote:
> 
> >Grr...  I know this have been brought up before, but why can't POV accept
> >dlls to add new features to it, like Moray? Yes, I know they're platform
> >specific - but it would be great if this ability could be added even just to
> >the Windows version.  Yeah, sure - I suppose they'd be quite a technical
> 
> it's not just technical. just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

Post a reply to this message

On Tue, 09 Feb 1999 19:50:06 GMT, povray.org admin team 
	<new### [at] DESPAMpovrayorg> wrote:
>"Matthew Bennett" <ben### [at] btinternetcom> wrote:
>
>>Grr...  I know this have been brought up before, but why can't POV accept
>>dlls to add new features to it, like Moray? Yes, I know they're platform
>>specific - but it would be great if this ability could be added even just to
>>the Windows version.  Yeah, sure - I suppose they'd be quite a technical
>
>it's not just technical. just imagine what it would be like if we started to
>have scene files floating around that depended on a particular mod being
>loaded. it'd fragment POV's standard, work-on-any-platform scene language
>into a bunch of platform-specific dialects.

As if that problem weren't already pretty severe with all the various 
patches out there.  If the cross-platform and other portability issues 
were resolved, though, I can see where the plugin concept would cause 
less of this problem than does the current system - especially if there
were a more-or-less centralized repository for plugins and if they were
required to be covered under either POVLEGAL or an Open Source license 
of some form.

At least with plugins, or the underlying architecture they'd require, 
adding most new unofficial features would be easier than modifying the 
current minimum of three files[1], if you should happen to need to 
recompile the plugin for your OS.  Having been through the process of 
merging sometimes-incompatible unofficial features[2] more times than 
I care to count, I can testify that it's often much more difficult than 
modifying a handful of files.  It shouldn't have to be that hard to
just add a new object, function, or texture.

[1] parse.h, [parse|parstxtr|express].c, tokenize.c
[2] and some official ones - most of the patches in the Superpatch 
    were originally written for version 3.0x and were originally 
    merged with that source base, so I merged in version 3.1 as if 
    it were just another patch.

Post a reply to this message

I don't think this would be tragic.  A cross-platform core could 
be supplimented with external libraries.  I don't see a bit problem
with this -- those wishing to publish public code will stick to the
core, while individual users will be able to exploit what is available
for their particular system.  It's better than holding everyone to
a minimal common denominator.

Things which encourage innovation and experimentation should in general
be pursued, not avoided.

Dan

"povray.org admin team" wrote:
> 
> it's not just technical. just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

-- 
http://www.flash.net/~djconnel/

Post a reply to this message

My opinion could sway to either side of this debate.
I once tried changing 'phong' and 'phong_size' to "gloss" and
"gloss_used" just for aesthetics, to use a more household word instead.
I went so far as to convert a few scene files so the name changes could
be recognized and made a few more new scenes too. BTW, I had to also
change my _surface.inc (customized finish.inc) and several other
includes to work with this custom pvengine.exe.
It wasn't long before I switched back due to the incompatiblity with so
many files, old or new. I still have custom includes I use for
everything from colors (_color.inc) to woods.inc (_wood.inc) which in
itself is not too compatible outside of my own environment here. Sure,
all the original stuff is still in them, but if I get an outside source
that requires the colors.inc, textures.inc, etc., I have to change those
filenames or leave copies of the originals around.
As you can see the ability to customize so many aspects can get garbled
in the translation. Even though I've heard mention before of
customizable keywords (which I found, during all that, keywords can't be
re-defined using #declare to solve the custom keyword problem) it
obviously gets chaotic enough just adding new includes that have to be
passed around to ensure renderability (don't we all know it!).
Guess that kind of goes with the territory though, which is why I said I
could see it both ways, but not easily. All in all, the argument for,
rather than against, plug-ins as stated by others seems a valid point.


"povray.org admin team" wrote:
> 
> just imagine what it would be like if we started to
> have scene files floating around that depended on a particular mod being
> loaded. it'd fragment POV's standard, work-on-any-platform scene language
> into a bunch of platform-specific dialects.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
=Bob

Post a reply to this message