> Thanks for trying, Vincent.  Can anybody else figure it out?  Perhaps Mr. 
> Yip is
> still out there...

1. Render base_terrain_v2.pov with the command line
+W1280 +H1024 +FN +A0.3 +R3
This will create a PNG for the height_field.

2. Move base_terrain_v2.png to where you want it, (688k)

3. Modify terrain.inc to refer the height_field path...
(Line 216 - 223), only the png portion really matters,
but make sure to move terrain_file into the #ifdef
so it doesn't raise an error. Like this...

#declare base_terrain = height_field {
   #ifdef (USE_PNG_HF)
      png "full file path\base_terrain_v2.png"
   #else
      sys terrain_file
   #end

4. Render povcomp.pov with the command line
+W960 +H1280 +FN +A0.4 +R3 +WL0 Declare=USE_HIGHRES_HF=1 
Declare=USE_PNG_HF=1
This should render the final image.
Eventually.
It's really, really slow.

Post a reply to this message

Tim Attwood a écrit :
> [snip]
> This should render the final image.
> Eventually.
> It's really, really slow.
> 

Well yeah that's pretty much equivalent to what is written in README.txt:

> Instruction on how to render the image
> 
> 1. Run "terrain.ini" to generate the heightfield bitmap.
> 2. Create a new folder call "hf" under the same folder as the rest of the source
>  files
> 3. Move "base_terrain_hd_v2.png" into "hf" (generated from terrain.ini)
> 4. Run povcomp.ini

But it does not work either (same error exactly)... On which OS did you try?

If indeed the image renders on Windows, we'll have to wonder what part 
works slightly differently on Linux...

-- 
Vincent

Post a reply to this message

Tim Attwood escribió:
>       png "full file path\base_terrain_v2.png"

Well, *that* won't work, because \b is a backspace character.

Always use forward slashes.

Post a reply to this message

>>       png "full file path\base_terrain_v2.png"
>
> Well, *that* won't work, because \b is a backspace character.
>
> Always use forward slashes.

No, it works fine.
It's easy to paste the path out of explorer in WindowsXP,
but it's back-slashes instead of forward-slashes.
The reason that this works is "full file path\base_terrain_v2.png"
is a string literal, not a string variable, the back-slash isn't interpreted
as an escape character in a literal.
If it makes you feel better to use forward slashes, that's fine too.

I'm not aware of any reason that this scene wouldn't render under
a Linux version of POV, though it does have many warnings which
are being suppressed by +WL0 in the command line.
I have 1 GB memory, maybe you have less? Sometimes POV
doesn't handle virtual memory as well as it should.

Post a reply to this message

Maybe Linux is freaking out about the division by zero
warnings?

** revisions to remove warnings
** in file "galleon.inc"
-----------------------------------------------------------------------------
** replace lines 141 - 145 with
               [0.0 color col]
               [0.1 color col]
               [0.5 color col2]
               [0.9 color col]
               [1.0 color col}
** explanation: RGB expects vector literal, color doesn't
-----------------------------------------------------------------------------
** replace line 1855 with
      #if (h_num=0) #local k=999999999; #else #local k = 1/h_num; #end
** explanation: remove division by zero error
-----------------------------------------------------------------------------
** replace lines 2114 - 2135 with
         // The lower cross beam for stern is broken... notice that the 
distance of
         // this beam below the platform is controlled by "overlap.x*2.5"
         #local TEMP_REVISION = cylinder {<0,0,cross_pole_l/2>,
            <0,0,-cross_pole_l/2>, 
base_pole_r*beam_crosspole_radius_factor};
         // main cross beam
         #if (show_decay > 0)
            #local TEMP_REVISION = union {
               object {TEMP_REVISION}
               object {m_dripping_cylinder(base_pole_r*
                  beam_crosspole_radius_factor*beam_deposit_level,
                  cross_pole_l)
                  rotate 90*y}};
         #end
         // Original plan is to cut the stern cross pole, Cut the center 
beam as well
         #if (special != bm_is_bow_beam)
            #local TEMP_REVISION = difference {
               object{TEMP_REVISION}
               object{galleon_cut_cross_beam
                  translate 
<-0.02,0,-(1-bm_stern_cross_beam_z)*(cross_pole_l/2)>}};
         #end
         object{TEMP_REVISION translate 
<base_cross_pole_x,base_cross_pole_y,0>}
         #undef TEMP_REVISION
** explanation: don't create a single object CSG
-----------------------------------------------------------------------------
** replace line 2823 with
   #local TEMP_REVISION =
** replace line 2885 with
      };    // difference
** replace line 2892 with
      #if (hull = hrm_is_top_hull) #local TEMP_REVISION = 
union{object{TEMP_REVISION}
** replace line 2898 with
         }};
** replace line 2900 with
         #if (show_decay > 0) #local TEMP_REVISION = 
union{object{TEMP_REVISION}
** replace line 2906 with
            }};
** replace line 2911 with
      object {TEMP_REVISION texture { t_galleon_hull_rail }
** explanation: don't create a single object CSG
-----------------------------------------------------------------------------

Post a reply to this message

That's it, Tim!  Step #3 is the important one.  Apparently the following works
on Windows but not Linux:

#declare base_terrain = height_field {
  #ifdef (USE_PNG_HF)
    png
  #else
    sys
  #end
  terrain_file
  ...
}

As Tim found, it must be in the form:

#declare base_terrain = height_field {
  #ifdef (USE_PNG_HF)
    png terrain_file
  #else
    sys terrain_file
  #end
  ...
}

So if you merely make the above tweak to terrain.ini you can render it as per
the author's readme file.  You will still get warnings but this time it will
progress past them.

So what clued you on to this, Tim?  I didn't see any complaints in the pov
output (but perhaps I missed it).

Does this warrant a bug report?


"Tim Attwood" <tim### [at] comcastnet> wrote:
>
> 3. Modify terrain.inc to refer the height_field path...
> (Line 216 - 223), only the png portion really matters,
> but make sure to move terrain_file into the #ifdef
> so it doesn't raise an error. Like this...
>
> #declare base_terrain = height_field {
>    #ifdef (USE_PNG_HF)
>       png "full file path\base_terrain_v2.png"
>    #else
>       sys terrain_file
>    #end
>

Post a reply to this message

Cruxic a écrit :
> That's it, Tim!  Step #3 is the important one.  Apparently the following works
> on Windows but not Linux:
> 
> #declare base_terrain = height_field {
>   #ifdef (USE_PNG_HF)
>     png
>   #else
>     sys
>   #end
>   terrain_file
>   ...
> }
> 
> As Tim found, it must be in the form:
> 
> #declare base_terrain = height_field {
>   #ifdef (USE_PNG_HF)
>     png terrain_file
>   #else
>     sys terrain_file
>   #end
>   ...
> }
> 
> So if you merely make the above tweak to terrain.ini you can render it as per
> the author's readme file.  You will still get warnings but this time it will
> progress past them.
> 

Well that's very strange, because on a simple test scene having png and 
the name of the file on different lines seems to work... There is 
probably something more evil at work behind the scene ;-)

Anyway, hats off to Tim for figuring it out!

-- 
Vincent

Post a reply to this message

> So what clued you on to this, Tim?  I didn't see any complaints in the pov
> output (but perhaps I missed it).

The file path provided raised an error, so I saw that
code, and remembered that you can't use concat to
form a filename in-place, it expects a literal or an
identifier, it just seemed simpler to move it.
Luck and experience I guess.

> Does this warrant a bug report?

Maybe, POV scenes should render the
same under any OS. Here's a minimal scene that
renders fine in Windows, does it work in Linux?

#version 3.6;

camera {
   location  <0.0, 0.5, -4.0>
   direction 1.5*z
   right     x*image_width/image_height
   look_at   <0.0, 0.0,  0.0>
}

light_source {
   <-30, 5, -30>
   color <1, 1, 1>
}

#declare VAR = 1;
#declare PATH = "plasma3.png";

height_field {
  #ifdef (VAR)
     png
  #else
     png
  #end
  PATH
  pigment {rgb <0,1,0>}
  translate <-0.5,0,-0.5>
  rotate <90,0,0>
  scale <2,2,1>
}

Post a reply to this message

> This should render the final image.
> Eventually.
> It's really, really slow.

	When I tried rendering this image after POVCOMP had the scripts
released, I noticed this very slow render speed had to do with the poor
bounding of some objects from the boat -- don't remember which exactly.
One possible, simple workaround has been to add an extra object around
the boat (e.g. a sphere) that's used only for bounding.  Then the rest
of the scene renders *much* faster.  I'll try to recover the modified
scene and will post it here.  But ideally it would be far better to
fix the bounding of those individual objects to also speed the boat
rendering.

	- NC

Post a reply to this message

Tim Attwood wrote:

> Maybe, POV scenes should render the
> same under any OS. Here's a minimal scene that
> renders fine in Windows, does it work in Linux?
> 
It renders fine on this:
Persistence of Vision(tm) Ray Tracer Version 3.6.1 (x86_64-pc-linux-gnu-g++
  4.2.4 @ x86_64-pc-linux-gnu)
This is an unofficial version compiled by:
  portage (on nbisgentoo64)

find it at:
http://ohnopublishing.net/~ohnobinki/images/sameonwindows.3.6.png

and on this:
Persistence of Vision(tm) Ray Tracer Version 3.7.0.beta.25b (g++ 4.1.2 @
  x86_64-unknown-linux-gnu)
This is an unofficial beta-test version compiled by:
  Nathan Phillip Brink <ohn### [at] ohnopublishinghomelinuxnet>

find the result at:
http://ohnopublishing.net/~ohnobinki/images/sameonwindows.3.7.png

I'm not sure where I set that alpha is default for 3.6, but that's what 
it looks like (I'm guesing).

Post a reply to this message