 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello!
I'm MCC900, 17 years old, born and living in Uruguay, South America.
I'm completely new at povray (well, not new, but I have very little experience
with it).
I need some help with a couple of things...
See, I'm highly interested in vegetation simulation using pov, and I've seen
some amazing examples out there...
Like Tom's Trees (http://www.aust-manufaktur.de/austt.html) or Norbert Kern's
vegetation simulation
(http://news.povray.org/povray.binaries.images/thread/%3Cweb.44b62d56a7a9ea94c436b710@news.povray.org%3E/).
About the second one, I'm interested on knowing how did Norbert manage to get
the vegetation adjust to the height field...
I just can't find the download link for it so I can't know how does the source
code works.
See, for adjusting the grass/plants to the height field, I was thinking in
getting the color of each pixel of the height field's base image...
Is that possible? Getting the color data of a determinated pixel in an image?
Well, anyway, I also need help with a very basic grass generator I've made...
Here's the code:
//Camera Settings
camera{location <0,0.2,0.1>
look_at <0,0,0.4>}
//Light Sources
light_source {
<0, 1, -3> color rgb<1,1,1>
}
//Ground
plane {y,0 pigment{rgb<0.2,1,0.2>}}
//Single Grass
#declare single_strand =
polygon { 11,
<-9,0>,<-6,30>,<0,60>,<8,83>,<18,97>,<14,90>,<9,77>,<3,40>,<3,18>,<5,0>,<-9,0>
scale 0.00025
}
//Generate Grass Extension
#declare R = seed (124573);
#declare zStart = 0;
#declare zEnd = 1.5;
#declare xStart = -1;
#declare xEnd = 1;
#declare i = zStart;
#declare j = xStart;
#while (i < zEnd)
#while (j < xEnd)
#declare C = rand(R);
#object{single_strand
rotate <0,rand(R)*360,0>
scale <rand(R)*0.5+0.5,rand(R)*0.3+0.7,1>
translate j*x
translate i*z
pigment{rgb<C/3,C*0.5+0.5,C/3>}
}
#declare j = j + 0.0025;
#end
#declare i = i +0.0025;
#declare j = xStart;
#end
It works pretty well (yeah, I know the grass look is very far away from real
grass) but the thing is, that if I want to make a big extension of field with
grass using this code, the parsing takes a lot of memory and the program lags...
I know there should be away to reduce the parsing memory, even if the redering
takes an entire day...
I have the feeling that I shouldn't be using while loops.
Thanks a lot for your time!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
By the way, I forgot the:
global_settings{assumed_gamma 0.8}
At the beggining of the code to avoid making the grass look so dark.
Also, here's a basic image of what the grass looks like, combined with a truly
bad attempt at making a 'cheesy' text:
http://i1034.photobucket.com/albums/a421/MCC900/Graphics%20Art/MCCCheeseGrass.jpg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"MCC900" <nomail@nomail> wrote:
.....
> get the vegetation adjust to the height field
.....
One method is to use the trace() function, an example is in the documentation.
Stephen S
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.07.2010 23:35, schrieb MCC900:
> //Single Grass
> #declare single_strand =
> polygon { 11,
> <-9,0>,<-6,30>,<0,60>,<8,83>,<18,97>,<14,90>,<9,77>,<3,40>,<3,18>,<5,0>,<-9,0>
> scale 0.00025
> }
> It works pretty well (yeah, I know the grass look is very far away from real
> grass) but the thing is, that if I want to make a big extension of field with
> grass using this code, the parsing takes a lot of memory and the program lags...
> I know there should be away to reduce the parsing memory, even if the redering
> takes an entire day...
> I have the feeling that I shouldn't be using while loops.
> Thanks a lot for your time!
When using objects over and over again, the mesh object is the most
memory efficient; while for most primitives (and also CSG compounds)
POV-Ray will create a full copy in memory for each instance, mesh copies
share a single instance of their bulk data among all copies (same goes
for blobs).
You don't want to make your meshes too "fine-grained" though, as each
instance still adds some overhead, so you may want to have a larger
patch of grass per mesh instead of just a single blade. This will also
speed up parsing time for placing the grass.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.07.2010 23:50, schrieb MCC900:
> By the way, I forgot the:
> global_settings{assumed_gamma 0.8}
> At the beggining of the code to avoid making the grass look so dark.
Don't. "assumed_gamma" is not intended for artistic purposes.
With POV-Ray 3.6, you should always use "assumed_gamma 1.0", and with
POV-Ray 3.7 you should leave out the "assumed_gamma" entirely. (Make
sure to set the Display_Gamma and, in case of POV-Ray 3.7, File_Gamma
INI parameters properly.)
If your grass looks too dark, instead toy around with the color (if you
picked it from Photoshop or the like, raise the RGB values to the power
of 2.2), the ambient parameter and/or the lighting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
@StephenS
>One method is to use the trace() function, an example is in the documentation.
Aha!
So I could go tracing rays directly from above the height field and finding the
inresections between them...
Slick! Thanks a lot.
@clipka
>You don't want to make your meshes too "fine-grained" though, as each
>instance still adds some overhead, so you may want to have a larger
>patch of grass per mesh instead of just a single blade. This will also
>speed up parsing time for placing the grass.
That was my first thought as well...
Having a patch of grass with a considerable size...
And having it to repeat over the field.
Still, I'm not sure on how can I achieve this...
How do I assign a patch of grass to a mesh.
Should be simple...
But I'm still a newbie.
>Don't. "assumed_gamma" is not intended for artistic purposes.
Yes. I know.
But what can I do...
I'm a pretty messy person, my codes are dull and I still use assumed_gamma.
You know what they say...
If it ain't broke... ;)
But well, I'll try to throw away those habits when I get down to something more
serious.
Thanks a lot for taking your time to answer me.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have another question...
See, I was playing around with isosurfaces and created one for making a
cylinder:
isosurface {
function {sqrt(x*x+z*z)-1}
threshold 0
accuracy 0.001
max_gradient 4
contained_by{sphere{0,2}}
pigment {rgb 1}
}
Pretty simple stuff.
The thing is, that if I enclose the function sqrt(x*x+z*z)-1 with the abs()
command...
isosurface {
function {abs(sqrt(x*x+z*z)-1)}
threshold 0
accuracy 0.001
max_gradient 4
contained_by{sphere{0,2}}
pigment {rgb 1}
}
The cylinder is not shown anymore!
I just don't get it...
If the result of sqrt(x*x+z*z)-1 is 0, when I find the absolute value of it, it
should still be 0... and if it's any other value, it shouldn't matter, as when I
find the absolute value of it it would not be 0 anyway...
So the isosurface should exist in the same area that the one without the abs()
command. Or not?
I need some help here, as I'm trying to create some more complex isosurfaces
using the abs() command, and I can't get on it if I still can't understand how
isosurfaces work...
I thought that if you take any point inside the isosurface's container, replace
the x, y and z values in the function for the values of the point, and the
result of the operation is equal to the threshold, the isosurface exists in that
point...
Is that correct?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I thought that if you take any point inside the isosurface's
container, replace
> the x, y and z values in the function for the values of the point,
and the
> result of the operation is equal to the threshold, the isosurface
exists in that
> point...
> Is that correct?
Yes, but in practice, POV-Ray can only find the point where the function
is equal to zero by evaluating it at various points along a ray, and
investigating where the function crosses from positive to negative. If
POV-Ray finds that the function is equal to 1 at point A, and 2 at point
B, it assumes that the function does not cross 0 between point A and B.
You need to have negative values on the inside of the object, so that
POV-Ray finds 1 at A and -2 at B, and investigates further between A and
B to find the surface.
What are you trying to accomplish by using abs()?
You might find that if you use {abs(sqrt(x*x+z*z)-1) - .1}, thus forcing
the function to be negative near the surface of the original sphere,
that you'll get a hollow sphere with a thickness of .2.
- Slime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 05.07.2010 01:04, schrieb MCC900:
> That was my first thought as well...
> Having a patch of grass with a considerable size...
> And having it to repeat over the field.
> Still, I'm not sure on how can I achieve this...
> How do I assign a patch of grass to a mesh.
> Should be simple...
First of all, you'll want to use mesh, not mesh2; they'd generate the
same data, but the former is usually easier to generate in SDL, while
the latter is better suited for automatic conversion of data (e.g. .obj
files converted for use in POV-Ray).
You'll also have to think a bit differently than you'd normally do with
CSG objects: You can't just compose a grass patch mesh by merging grass
blade sub-objects - you'll have to make it one huge bunch of triangles.
Maybe the easiest way to do it might be as follows:
- Think of how you'd model a single grass blade using only triangles.
Store the necessary data in one or more arrays. (For instance, you could
simply use one array of triangle corner points, with three consecutive
entries defining a triangle.)
#declare GrassTriangleCount = ...;
#declare GrassPoints = array[GrassTriangleCount*3] {
<...>, <...>, <...>,
<...>, <...>, <...>,
...
}
#declare GrassPatch = mesh {
- Set up a loop construct to iterate over all the coordinates where you
want to "plant" a grass blade inside the patch (e.g. two nested loops to
iterate over over X and Y).
#local X = 0;
#while (X < 100)
#local Y = 0;
#while (Y < 100)
- In each iteration, compute the transformation you want to apply to
this individual grass blade; you'll probably want a random rotation,
maybe some random scaling, and of course the translation to its place.
#local BladeTrans = transform {
rotate y * 360*rand(R)
scale 0.5 + rand(R)
translate <X/100-0.5, 0, Y/100-0.5>
}
- Then, iterate over all the triangles in your array, inserting them
into the mesh with the transformation applied.
#local I = 0;
#while (I < GrassTriangleCount*3)
triangle {
vtransform(GrassPoints[I + 0], BladeTrans),
vtransform(GrassPoints[I + 1], BladeTrans),
vtransform(GrassPoints[I + 2], BladeTrans)
}
#local I = I + 3;
#end
- Finally, close the loops and the mesh.
#local Y = Y + 1;
#end
#local X = X + 1;
#end
}
There: A simple patch of grass.
To avoid obvious repetitions when using the patch, you may want to
rotate each copy randomly, or even generate a set of, say, five
different patches to pick from.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
@clipka
Great!!
I followed your steps and succesfully managed to decrease the parsing time.
I created 4 different patches of grass, giving each one of them a random
rotation as you suggested...
The result is fairly good and the repetition of the grass is completely
imperceptible. By combining this big exstension of grass with one 2x2
grass patch 'attached' to a height map representing a hill, and by adding some
stones and random flowers, I kinda avoided the cold look of a totally flat
field.
I'd post an image but I only rendered a very small version of it, which actually
took 4 hours to render due to the flowers, so...
Thanks a lot for your time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
