On Wed, 16 Jan 2008 17:41:51 EST, "SharkD" <nomail@nomail> wrote:

>// put some sections together to build a road
>#declare o_Road =
>  union {
>    #declare S = 0;
>    #while (S < 10)
>    union {
>      #declare Z = 0;
>      #declare section_translate = z*S*20*(4+l_Gap)/12;
>      #while (Z < 20)
>        #declare X = 0;
>        #while (X < 20)
>          #declare brick_translate = <(X-10 #if(Z/2=int(Z/2)) +0.5
>#end)*(8+l_Gap), 0, Z*(4+l_Gap)>/12;
>          object {
>            o_Brick
>            texture {
>              pigment { eval_pigment(p_Brick, x*rand(l_Seed)) }
>            }
>       texture {
>         pigment {p_Stripe_z}
>         translate x*.5
>         scale 10
>         translate -brick_translate
>         translate -section_translate
>       }
>            translate brick_translate
>          }
>          #declare X = X + 1;
>        #end
>        #declare Z = Z + 1;
>      #end
>   translate section_translate
>    }
>      #declare S = S + 1;
>    #end
>  }

SharkD,

What you've done here is nothing more than nesting unions to build the complete road
brick by brick, which will be a huge memory hog.  It's basically the same as removing
the outer union and loop (the
one using the S variable), and then increasing Z to a value of Z*S.  In the original
code, the road is built from predefined sections of bricks, which consumes
considerably less memory and saves allot
of parse time as compared to the brick by brick method.  Plus, I think the way you're
applying the second texture will still show breaks between the sections.

I think I'm going to have to change my scene.  Instead of having the brick road fade
out into the distance, I may try curving it enough to have it diminish from view more
quickly.  Another possibility
is that I may use the brick by brick method to a point, and then switch over to
another object for the distant bricks, such as a box with a home-brewed brick pattern
applied.

I still think a method to layer a texture over a union of individually textured
objects would be a greatly welcomed feature addition to POV-Ray.  This isn't the first
time I've run into a circumstance
where such a feature would provide the simplest solution to a problem.

Post a reply to this message

Kyle wrote:
> Perhaps someone can help me figure out a way to do this...
> 
> I've built a brick road by unioning several hundred bricks to create a section of
road, and then
> laying the sections end to end to form the complete road.  Each brick in a section
has a different
> texture.  Now, I'm trying to add stripes to the road.  I can do it within the
texture statement used
> for the bricks, but that creates stripes that are too uniform.  I'd like to have
some curvature and
> disparities in the stripes, which I cannot figure out how to do without the
disparities being
> obviously duplicated in each section.  Any ideas?
> 
> This is where I think a texture override would be very helpful.  The road could be
built as above,
> unioning bricks to form sections and then unioning the sections to form the road. 
Then an overall
> texture could be applied that defines the stripes for the entire union.  This would
be helpful for
> applying dirt textures too.
> 
> Any help would be appreciated.

One possibility is that you might want to consider modeling the paint as 
an object and not a texture.  Real paint has thickness, and the 
thickness of road paint is often very significant.

If you are making the bricks from a height field that is based on a 
pigment pattern, then you can slightly modify the pattern (with an 
average statement) to raise the value of it where the stripe is and 
lower it in other places; then use that modified height field to model 
the stripes.

Regards,
John

Post a reply to this message

Kyle <hob### [at] gatenet> wrote:
> SharkD,
>
> What you've done here is nothing more than nesting unions to build the complete road
brick by brick, which will be a 
huge memory hog.  It's basically the same as removing the outer union and loop (the
> one using the S variable), and then increasing Z to a value of Z*S.  In the original
code, the road is built from pre
defined sections of bricks, which consumes considerably less memory and saves allot
> of parse time as compared to the brick by brick method.  Plus, I think the way
you're applying the second texture wil
l still show breaks between the sections.
>
> I think I'm going to have to change my scene.  Instead of having the brick road fade
out into the distance, I may try
 curving it enough to have it diminish from view more quickly.  Another possibility
> is that I may use the brick by brick method to a point, and then switch over to
another object for the distant bricks
, such as a box with a home-brewed brick pattern applied.
>
> I still think a method to layer a texture over a union of individually textured
objects would be a greatly welcomed f
eature addition to POV-Ray.  This isn't the first time I've run into a circumstance
> where such a feature would provide the simplest solution to a problem.

I did this to illustrate the fact that, in order for the texture not to repeat
for each section, the value for S must be passed to the texture. This is not
possible if the declaration of the object comes before the declaration of the
parameter, S.

This was in response to your remark that my *earlier* suggestion would not work
for this reason. If you combine the two methods (e.g., define an object that
gets re-used for each section, apply a texture to each re-use of this object
that takes into account the parameter S), it will work.

Post a reply to this message

On Thu, 17 Jan 2008 20:29:42 EST, "SharkD" <nomail@nomail> wrote:

>I did this to illustrate the fact that, in order for the texture not to repeat
>for each section, the value for S must be passed to the texture. This is not
>possible if the declaration of the object comes before the declaration of the
>parameter, S.

Yes, I'm well aware of that.  It's one part of the problem.

>This was in response to your remark that my *earlier* suggestion would not work
>for this reason. If you combine the two methods (e.g., define an object that
>gets re-used for each section, apply a texture to each re-use of this object
>that takes into account the parameter S), it will work.

But the way your new code is written, you're basically building the entire road
brick-by-brick and
not resuing any objects.  The inner union is of no use, as is the S loop if you just
loop Z S*Z
times.

The brick-by-brick method is what I did originally, until I realize the amount of
memory that is
utilized to build a road of any lenght.  If you're curious, try building a road using
these two
methods and do a comparison of the peak memory used:

1) Build a 35x100 brick section.  Lay down 20 sections end-to-end to build the road.

2) Build a 35x2000 brick section.  That's your road.

Number two will consume allot more memory than number one for the same size road. 
Because the scene
i want to build will contain many objects in addition to this road, I have to consider
the amount of
memory that's used to avoid swapping (drive thrashing).

On the other hand, a layered texture can be used across the entire road in number two,
wheras it
cannot be in number one, providing that each brick is textured independently in both
cases.

Perhaps that better explains the problem and better defines the need for a way to
layer a texture
over a union of individually textured objects.

Post a reply to this message

On Thu, 17 Jan 2008 18:13:50 -0500, John VanSickle <evi### [at] hotmailcom>
wrote:

>One possibility is that you might want to consider modeling the paint as 
>an object and not a texture.  Real paint has thickness, and the 
>thickness of road paint is often very significant.

I did try that, but was not satisfied with the result.  I'm going for the old brick
road look, where the paint for the lines is usually only visible around the worn
sections on the top of the bricks.

>If you are making the bricks from a height field that is based on a 
>pigment pattern, then you can slightly modify the pattern (with an 
>average statement) to raise the value of it where the stripe is and 
>lower it in other places; then use that modified height field to model 
>the stripes.

Hmm, I may look into using a height field.  I think the resolution that it'd require
may be a little high, but I could possibly reduce the resolution as the road sections
get further away.  I'll have
to do some experimenting with that idea.  I've also considered writing a macro to
build the whole thing out of a mesh.

Thanks for your reply.

Post a reply to this message

Kyle <hob### [at] gatenet> wrote:
> Yes, that's part of the problem.  The bricks are not flat, but are randomly skewed
to look more realistic.  I may sti
ll be able to use this idea, or perhaps the non-transparent road idea as outlined
above.

Have you tried 'snowing' Blob objects onto the bricks?

This involves casting rays within the script, and placing blobs at the
intersections with your bricks. You could probably impose a condition on the
intersection position to avoid the gaps.

I've seen a "snow scene" demo script that might help with this (can't remember
where I saw it) - I think with a school bus and a twig in it too.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SharkD wrote:
 I did this to illustrate the fact that, in order for the texture
not to repeat
> for each section, the value for S must be passed to the texture. This is not
> possible if the declaration of the object comes before the declaration of the
> parameter, S.
> 
> This was in response to your remark that my *earlier* suggestion would not work
> for this reason. If you combine the two methods (e.g., define an object that
> gets re-used for each section, apply a texture to each re-use of this object
> that takes into account the parameter S), it will work.
> 
	In fact, you can manage something similar with a single texture
using the "repeat" warp. For example (untested, so may need some
tweaking):

texture {
   pigment {p_Stripe_z}
   translate x*.5
   scale 10
   translate -10*x

   warp {
      repeat x*(8+l_Gap)
   }
   warp {
      repeat z*21*(4+l_Gap)/12
      offset x*(8+l_Gap)/2
   }
}

	See: http://povray.org/documentation/view/3.6.1/407/

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHkRm7d0kWM4JG3k8RAoPhAJ93dy+sdTo8CXVKRdpIN4AYGi4DBACfRZQR
NfqMxXhb4jBmgUz68G6NH8k=
=Rtxv
-----END PGP SIGNATURE-----

Post a reply to this message

Why not try the following code which I created that combines the two methods I
provided in my previous posts?

// build a section of brick road
#declare o_Section =
  union {
    #declare Z = 0;
    #while (Z < 20)
      #declare X = 0;
      #while (X < 20)
        #declare brick_translate = <(X-10 #if(Z/2=int(Z/2)) +0.5
#end)*(8+l_Gap), 0, Z*(4+l_Gap)>/12;
        object {
          o_Brick
          texture {
            pigment { eval_pigment(p_Brick, x*rand(l_Seed)) }
          }
          translate brick_translate
        }
        object {
          o_Brick
          scale y * 1.001
          translate brick_translate
        }
        #declare X = X + 1;
      #end
      #declare Z = Z + 1;
    #end
  }


// put some sections together to build a road
#declare o_Road =
  union {
    #declare S = 0;
    #while (S < 10)
      #declare section_translate = z*S*20*(4+l_Gap)/12;
      #declare brick_translate = 2*(20-10)*(8+l_Gap)/12;
      object {
        o_Section
        texture {
          pigment {p_Stripe_z}
          translate x*.5
          scale brick_translate
          translate -section_translate
        }
        translate section_translate
      }
      #declare S = S + 1;
    #end
  }

object { o_Road }

Post a reply to this message

SharkD,

I haven't tried it yet, but that looks like a pretty good solution.  

I mentioned before that there may be some coinciding surfaces issues by just scaling
the bricks, but
they may not be visible enough for concern.  

OTOH, I could difference a brick translated in the y direction with a scaled brick to
avoid that
problem.  Instead of this ...

        object {
          o_Brick
          scale y * 1.001
          translate brick_translate
        }

... perhaps something like this ...

        difference {
          object { o_Brick translate y*0.01 }
          object { o_Brick scale 1.001}
          translate brick_translate
        }

Thanks for sticking with it!

Post a reply to this message

> As you'll see in this scene, the bricks in each section are textured 
> with individual pigment values. Because of this, any texture applied
> to the o_Road object has no impact. I can apply the stripes to the
> bricks as they are created, but doing so causes obvious uniformity in
> the stripes. I'd rather have the stripes not be uniform and instead
> have some slight curvature to them as they are drawn down the road.
> Furthermore, I'd also like to be able to apply an overall "dirt"
> texture that is more pronounced at the edges of the road and not
> obviously uniform.
> 

If you put the normal texture, and then the dirt texture (one after the 
other, as layered textures), each brick would look the same. But try 
putting the dirt texture *after translating the brick into place*. That 
will make the dirt texture centered on the origin of the scene (well, 
not exactly), while keeping the base texture centered on the origin of 
the brick before translating.

It should look the same as if you had put the dirt texture on the whole 
union with all the bricks.

Post a reply to this message