This patch lets one directly load Leveller or Terragen .TER files
in POV-Ray for use as heightfields (WinPOV binary for now):

http://www.daylongraphics.com/other/povgl/povbin_ter.zip

It may also work to load imagemaps (as 16-bit grayscale)
but this has not been tested.

Source code for interested parties will be
available as well soon.

Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

On Thu, 12 Jun 2003 18:04:19 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:
> Source code for interested parties will be
> available as well soon.

Ray, I have not Terragen experience so I can't review it but I have side note
about your releases. First of all I think you really should change splash
screen. It looks like it is an official version (no indication that the one in
the middle of image is not related with the one at bottom of image). I think
there is a lot possibilities indicating Preview+Terragen+POV so there shouldn't
be problem with creating something different.

Other thing is that releasing only binaries breaks license:

    Custom versions may  only be distributed  as freeware and  under terms
    no  less  restrictive  than  this  license.  You must make all of your
    modifications  to  POV-RayÖ  freely  and  publicly available with FULL
    SOURCE  CODE  to  the  modified  portions  of POV-RayÖ and must freely
    distribute full  source to  any new  parts of  the custom version.

I also broke it once for very initial version of PoPOV thought I consulted it
with TAG Member earlier and released sources as soon as possible after binaries.
I doubt POV-Team will be cruel for this violation but you have to know all
rules.

ABX

Post a reply to this message

>
> Ray, I have not Terragen experience so I can't review it but I have side
note
> about your releases. First of all I think you really should change splash
> screen.

I'll be making a more customized one soon, but for now it was easier
to just take the existing one and overlay text (big, bold text) on it. At
least I made
sure that the word "patch" was obvious. :)  It was also the easiest
way to ensure that all the POV-Team's copyright notices were intact,
which is a requirement.


> Other thing is that releasing only binaries breaks license:

No kidding? That's why the source will be up soon (in fact, later today).
But getting it all nicely organized and documented takes time.
If someone's in a rush, they can have my source sooner, but
it will just be a crude zip of whatever's on my drive at the moment.

If the POV-Team has a problem, they can always send me an email.
That's one reason I post patches here, so that they're the first to know.
I appreciate your concern, but there's nothing going on here.

Ray

Post a reply to this message

The source code for this patch is now available at
http://www.daylongraphics.com/other/povgl/povgl.zip


Ray Gardener
Daylon Graphics Ltd.
"Heightfield modeling perfected"
http://www.daylongraphics.com

Post a reply to this message

On Fri, 13 Jun 2003 13:14:34 -0700, "Ray Gardener" <ray### [at] daylongraphicscom>
wrote:

> > Other thing is that releasing only binaries breaks license:
>
> I appreciate your concern, but there's nothing going on here.

I know, but starting correct makes less changes later and builds vision of your
person in serious later cooperation. BTW, there is another violation of license.
Last paragraph of http://www.daylongraphics.com/other/povray/patches/ is:

  The Usual Disclaimer 

  The code is still under development and is not warranted nor supported by me 
  or by Daylon Graphics Ltd. 

while POV license says clear:

  You must provide all support for all users who use your custom version.

Another important issue broken in your TER patch is this part of POV license:

  If  your  custom  version  contains  any  feature  that  would cause a
  POV-Ray   scene  source  file  that  works  on your version to fail or
  otherwise work incorrectly on  either the current official  version of
  POV-Ray , or on the official  version that was built from  the version
  of the source  that you are  using for your  custom version, you  must
  include code  that checks  that the  scene source  file has a #version
  directive  that  includes  the  'unofficial'  token, and you must only
  activate your changes  (including, but not  limited to, new  keywords)
  if  that  #version  directive  is  present.  If it is not present your
  custom version  must work  in the  same way  as the  standard  POV-Ray
  that it is built from.  An example of a correct  'unofficial' #version
  declaration is '#version unofficial megapov 0.7 ;'. 

Carrying for community is as much important as delivering attractive features.

BTW 1, it would be great if in TER patch some sample TER file could be attached
with sample scene.

BTW 2, are you sure that all exe files listed in INTRODUCTION section of
readme's are fully available ?

BTW 3, your changes in sources are nicely documented but would it be possible to
change naming of switches to something with PATCH string? See
http://megapov.inetart.net/manual/internals.html#markup for details.

BTW 4, there is a note in TER patch description: "Since the xxx_FILE constants
in frame.h have no room for additional filetypes (not if each type has to be a
bitmask, anyway), the patch works by loading the TER file and then pretending
that it loaded a PNG grayscale file. It's inelegant, but it works."
Look for MPEG_PORT_PATCH in MegaPOV 1.0 sources. This is probably more 'elegant'
and expected solution.

BTW 5, are:
	#pragma comment(lib, "opengl32")
	#pragma comment(lib, "glu32")
and
	#include "gl\gl.h"
	#include "gl\glu.h"
part of larger library or just win32 specific components ? Don't you think it is
worth to list this library in banners like for LibPNG etc?

ABX

Post a reply to this message

ABX wrote:
> 
> [...]
> 
> I know, but starting correct makes less changes later and builds vision of your
> person in serious later cooperation. BTW, there is another violation of license.
> Last paragraph of http://www.daylongraphics.com/other/povray/patches/ is:
> 
>   The Usual Disclaimer
> 
>   The code is still under development and is not warranted nor supported by me
>   or by Daylon Graphics Ltd.
> 
> while POV license says clear:
> 
>   You must provide all support for all users who use your custom version.

While i agree the used wording is not perfect i think you exaggerate this
point a bit.  The licence cannot force you to provide any specific support
for the user of a patch like helping him understanding how to use it or
fixing a bug.  The main idea behind this part of the licence is to make
the patch author being the one to contact about (purely voluntary) support
and not the POV-Team.  

The motivation behind this 'disclaimer' obviously is to avoid legal
liability for the usage of these patches - the POV-Ray licence does not
handle this so the patch author has to take care of this himself (although
you can argue that you don't have to explicitly state it when the program
is accessible for free and for everyone like in this case).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 16 Jun 2003 20:41:23 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> >   You must provide all support for all users who use your custom version.
>
> While i agree the used wording is not perfect i think you exaggerate this
> point a bit.

The only thing I wanted to exaggerate was that it is unpolite to the user to
release application and explicitly write something like "I do not support you".
At least "this is under development version and features changes dynamically,
feel free to ask any question to ..." is more human imo ;-) But I hope Ray
understand that my notes are not fully serious but some reviewing pointers
especially that he used sup### [at] daylongraphicscom for contacting :-) I'm trying
to be helpful rather than offensive.

ABX

Post a reply to this message

> while POV license says clear:
>
>   You must provide all support for all users who use your custom version.

I'm just saying this stuff is prototype material; obviously
I'm not going to spend time fixing someone's use of the code
unless it happens to dovetail with my ongoing patch work.
Chris's note is well taken; I think POVLEGAL would phrase
it better to say "The POV-Team is not responsible for supporting
custom versions, and patch developers must not claim or imply
that it is." because that's the spirit of the agreement.



>   If  your  custom  version  contains  any  feature  that  would cause a
>   POV-Ray   scene  source  file  that  works  on your version to fail...

Yeah, that should be in.



> BTW 1, it would be great if in TER patch some sample TER file could be
attached
> with sample scene.

There's a sample Leveller TER available at
http://www.daylongraphics.com/products/leveller/download/testdoc.zip


> BTW 2, are you sure that all exe files listed in INTRODUCTION section of
> readme's are fully available ?

pvengine_daylon_ogl.exe isn't currently available,
but the intro section only lists what packages
might exist, not which ones actually exist.
The functionality is in pvengine_daylon.exe,
and the full source for all patches is always available.
It's not efficient for me to sit here and build
every possible permutation, especially when the
code is changing day by day.



> BTW 3, your changes in sources are nicely documented but would it be
possible to
> change naming of switches to something with PATCH string? See
> http://megapov.inetart.net/manual/internals.html#markup for details.

"DAYLON" is a standard mod identifier prefix my company uses.
I have tools that grep for it through several other
projects, etc. so it's not going to change.

At the end of the day, it's just a patch. I'm on information overload,
and not to belittle things, but I really can't cross every T and dot every
I.



> BTW 4, there is a note in TER patch description: "Since the xxx_FILE
constants
> in frame.h have no room for additional filetypes (not if each type has to
be a
> bitmask, anyway), the patch works by loading the TER file and then
pretending
> that it loaded a PNG grayscale file. It's inelegant, but it works."
> Look for MPEG_PORT_PATCH in MegaPOV 1.0 sources. This is probably more
'elegant'
> and expected solution.

Yeah, they've gone and shifted the bitmasks for several other
macros over to make room. But ultimately there's only so much room.
The filetype IDs should really be enum ordinals instead of bitmasks;
hopefully they'll do that in 4.0.

What I really wanted to do was patch POV so that it didn't
bother retaining filetype info after texture loading anyway,
because it's unnecessary. The pixels are converted into a
generic internal representation anyway. Instead of testing
all the filetypes in a big switch block during texture access,
it'd be better to just skip to the high-level Image struct attributes
like IS16GRAYIMAGE and go on that. Only the texture I/O code
should care about the filetype; it makes adding/removing filetypes
much easier. If they wanted to differentiate between different
texture types they should have constants like IS_MOVIE, IS_HEIGHTFIELD,
IS_MASK, or better still, just make an abstract CTexture or CImagemap
base class and subclass it to CMovie, CHeightfield, CMask, etc.
Then you have a base factory class like CTextureIO which
returns a base CTexture reference to a specific CTexture subclass
that it made when loading the bitmap e.g.:

   CTextureIO txIO(pszFilename);
   CTexture* pTexture = txIO.Read();


and CTextureIO::Read() does something like:

   // Create an object to handle the image format (bmp, jpeg, etc.).
   CImageFormatHandler* pFormatHandler =
     CTextureIOFactory::Instance(GetFileType(m_pszFilename));

   // Make a texture of the right type (grayscale, hf, rgb, indexed, etc.)
   CTexture* pTexture =
     CTextureFactory::Instance(pHandler->GetImageType());

   // Have the format handler load the texture.
   pFormatHandler->ReadInto(pTexture);
   delete pFormatHandler;

   return pTexture;


So now all the switch(filetype) stuff is in factory classes,
the format details are encased in specific IO classes,
and the rest of the code can work on an abstract level.
I'd also abstract filenames to a CFileID type, since
Macs use FSSpec records, but you see what I mean.


> BTW 5, are:
> #pragma comment(lib, "opengl32")
> #pragma comment(lib, "glu32")
> and
> #include "gl\gl.h"
> #include "gl\glu.h"
> part of larger library or just win32 specific components ? Don't you think
it is
> worth to list this library in banners like for LibPNG etc?

No. OGL is OEM stock included on Win32, so mentioning it
would be like mentioning gdi32.exe. On Linux, mentioning Mesa
might be proper, since it's a third-party lib.

Ray

Post a reply to this message

Ray Gardener wrote:
> I think POVLEGAL would phrase
> it better to say "The POV-Team is not responsible for supporting
> custom versions, and patch developers must not claim or imply
> that it is." because that's the spirit of the agreement.

as a side note see bottom frame at
http://megapov.inetart.net/manual/appendices.html#megapov_authors

> > BTW 1, it would be great if in TER patch some sample TER file could be attached
> > with sample scene.
>
> There's a sample Leveller TER available at
> http://www.daylongraphics.com/products/leveller/download/testdoc.zip

Thanks, will see it.

> > BTW 3, your changes in sources are nicely documented but would it be possible to
> > change naming of switches to something with PATCH string? See
> > http://megapov.inetart.net/manual/internals.html#markup for details.
>
> "DAYLON" is a standard mod identifier prefix my company uses.
> I have tools that grep for it through several other
> projects, etc. so it's not going to change.

your grep will not catch DAYLON_OGL_PATCH, DAYLON_TER_PATCH ?

> What I really wanted to do was patch POV so that it didn't
> bother retaining filetype info after texture loading anyway,
> because it's unnecessary.

I do not investigated details but I wonder if it makes your patch compatible
with 'IO restrictions' idea introduced in 3.5?

ABX

Post a reply to this message

> as a side note see bottom frame at
> http://megapov.inetart.net/manual/appendices.html#megapov_authors


Isn't Nathan Kopp a member of the POV-Team also?
Does that mean the POV-Team is helping write MegaPOV?
But then the POV-Team isn't responsible for it.
Wait a minute... hmm...


> your grep will not catch DAYLON_OGL_PATCH, DAYLON_TER_PATCH ?

My macro names are long enough already.


> > What I really wanted to do was patch POV so that it didn't
> > bother retaining filetype info after texture loading anyway,
> > because it's unnecessary.
>
> I do not investigated details but I wonder if it makes your patch
compatible
> with 'IO restrictions' idea introduced in 3.5?

I don't see how it wouldn't. If the filename or fileID for an
imagemap has been qualified by code prior to the
texture loader classes ever using it, then the
loader code itself would have to be hacked to overrule
the qualification, which is true of official POV.
You'd have something like:

  CExternalSceneResourceQualifier qualifier(pszFilespec);
  if(!qualifier.Okay() &&
     WarnUser("File %s is possibly dangerous to read\n", pszFilespec)
      == user_responses::abort)
      return;

  // load the texture as before, passing filespec as 'const'



Ray

Post a reply to this message