 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Thanks for your comments.
I actually gave some wrong information on the RMF. I apologize.
The scene was left on my HD for abt. 4 weeks and after returning
from holiday I decided to post it asap. Should have recalled
the sources before.
Ok then. The mountains are a superposition of three components:
- a basic RMF
- a large scale pigment function using granite
- a fine scale pigment function using granite that adds
more fine structure to the surface
The latter two components are modulated by y in order to
increase their weight for higher altitudes.
The following code snipped illustrates this:
#declare Ridges = function {
"ridgedmf", <0.5, 2.0, 5.0, 0.3, 20.0>
}
#declare Granfunc = function {
pigment {
granite
color_map {
[0 rgb 0]
[0.5 rgb 1]
[1 rgb 0]
}
}
}
#declare Xshift = 18;
isosurface {
function { y - 12*Ridges(0.05*(x+Xshift),0,0.05*z)
- 0.10*y*Granfunc(0.5*(x+Xshift),0.5*y,0.5*z)
- 0.024*y*Granfunc(1.5*(x+Xshift),1.5*y,1.5*z) }
contained_by{ box {<-500, -1, -50>, <500, 7, 500>}}
max_gradient 12
accuracy 0.000001
method 2
texture { T_Ridges_High }
}
I'll soon render a more detailed view of parts of the mountains.
-Hans-
Christoph Hormann schrieb:
>
> Hans-Detlev Fink wrote:
> >
> [...]
> >
> > Enjoy
> >
>
> I'm doing !
>
> I really like the mountains, could you make a closeup of some mountain parts,
> they really look very different from normal RMF, so i wonder how you did that.
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmx de>
> Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Thanks very much for that detailed explanations, the RMF parameters are quite
interesting, i have never used such values.
The isosurface function was a bit irritating first, because i usually do the
scaling and translation in the pigment (this allows to test the components as
textures, which is a lot faster than on the isosurface) but it surely also works
this way.
I somehow wonder about the low max_gradient, in my last landscape i got values
around 100-200 using eval, but i can't see any errors in your picture.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
The rocks and snow look really good, the atmospheric effect
is good aswell. Nice work.
--
Cheers
Steve email mailto:ste### [at] zeropps uklinux net
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
3:15pm up 8 days, 19:34, 2 users, load average: 1.00, 1.00, 1.00
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Seems like You live in southern part of Bayern, look out of window and
render...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Vahur Krouverk wrote:
>
> Seems like You live in southern part of Bayern, look out of window and
> render...
In summer ?
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Wed, 30 Aug 2000 12:06:33 +0200, Hans-Detlev Fink wrote...
> The snowy rocks are a superposition of 2 RMFs.
> The tree: thanks to Andrew Clinton for his splinetree.
> The grass: thanks to Gilles Tran for his mesh grass.
>
> The color banding is due to jpg compression, this
> scene needs big size to make the glass look lost in
> the ice desert.
I was looking at this, when I had an idea you'll probably hate... <grin>
If it were possible to alter Gilles' macro to create a 'grass' of tree
objects, then you could have a more useful sense of scale, with the large
tree in the centre of the dome representing the 'tree of life' from
various mythologies.
Of course it would be almost impossible to tell that the 'grass' was
actually a forest canopy at the size it would render.
Oh, and I really like the image BTW, it reminds me of various console
RPG's set in post apocalyptic worlds where some technologies are still
functioning.
Bye for now,
Jamie.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Jamie Davison wrote:
>
> If it were possible to alter Gilles' macro to create a 'grass' of tree
> objects, then you could have a more useful sense of scale, with the large
> tree in the centre of the dome representing the 'tree of life' from
> various mythologies.
>
> Of course it would be almost impossible to tell that the 'grass' was
> actually a forest canopy at the size it would render.
>
You don't need Gilles' macro to do that. Something like the following
(untested) code should do:
#declare S = seed (1234);
#declare Jitter = 0.2;
#declare X = 0;
#while (X < 100)
#declare Y = 0;
#while (Y < 100);
object {
Tree
translate <X+Jitter*rand (S), 0, Y+Jitter*rand(S)>
}
#declare Y = Y + 1;
#end
#declare X = X + 1;
#end
Of course, it needs to be adapted to the size of the trees (something
like 0.4 units wide in this example). Note that if you use a mesh tree,
this shouldn't use too much memory but if you use a blob or CSG tree,
your computer probably won't have enough memory to do it...
--
* Doctor Jekyll had something * mailto:ber### [at] iname com
* to Hyde... * http://www.enst.fr/~jberger
*******************************
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Jamie Davison wrote:
> I was looking at this, when I had an idea you'll probably hate... <grin>
>
> If it were possible to alter Gilles' macro to create a 'grass' of tree
> objects, then you could have a more useful sense of scale, with the large
> tree in the centre of the dome representing the 'tree of life' from
> various mythologies.
This is a very nice idea, worth a separate project, and I do not at
all hate it. Though, this wouldn't be possible with Gilles' macro
since it's a mesh. OTOH, with other grass macros I've seen it
shouldn't be a big problem, but sloooow ...
>
> Of course it would be almost impossible to tell that the 'grass' was
> actually a forest canopy at the size it would render.
I agree with the other posters that the scale and/or perspective
have to be changed anyway.
>
> Oh, and I really like the image BTW, it reminds me of various console
> RPG's set in post apocalyptic worlds where some technologies are still
> functioning.
>
Thank you. Yes, this and various other scenarios come to mind.
-Hans-
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Christoph Hormann wrote:
>
> Thanks very much for that detailed explanations, the RMF parameters are quite
> interesting, i have never used such values.
RMF parameters being an endless story ...
>
> The isosurface function was a bit irritating first, because i usually do the
> scaling and translation in the pigment (this allows to test the components as
> textures, which is a lot faster than on the isosurface) but it surely also works
> this way.
Well, actually I didn't spend much brain on code design here, just
a "grown project", you know ;)
>
> I somehow wonder about the low max_gradient, in my last landscape i got values
> around 100-200 using eval, but i can't see any errors in your picture.
Yes, I started with even smaller values and then eval gave something
like 11.xx. Values around 8 definitely produce discontinuities and
gaps in the surface.
-Hans-
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On Thu, 31 Aug 2000 10:21:40 +0200, =?iso-8859-1?Q?J=E9r=F4me?= Berger
wrote...
> > If it were possible to alter Gilles' macro to create a 'grass' of tree
> > objects, then you could have a more useful sense of scale, with the large
> > tree in the centre of the dome representing the 'tree of life' from
> > various mythologies.
> >
> > Of course it would be almost impossible to tell that the 'grass' was
> > actually a forest canopy at the size it would render.
> >
> You don't need Gilles' macro to do that. Something like the following
> (untested) code should do:
>
> #declare S = seed (1234);
> #declare Jitter = 0.2;
> #declare X = 0;
> #while (X < 100)
> #declare Y = 0;
> #while (Y < 100);
> object {
> Tree
> translate <X+Jitter*rand (S), 0, Y+Jitter*rand(S)>
> }
> #declare Y = Y + 1;
> #end
> #declare X = X + 1;
> #end
>
> Of course, it needs to be adapted to the size of the trees (something
> like 0.4 units wide in this example). Note that if you use a mesh tree,
> this shouldn't use too much memory but if you use a blob or CSG tree,
> your computer probably won't have enough memory to do it...
Ah, but this relies on you speaking fluent POV code... I don't, I speak
Moray relatively fluently <grin>
The reason I mentioned modifying Gilles' macro is that that was what Hans
said he was using, and I, in my innocence of such things <grin> assumed
it would be easier to alter existing code to do something than to rewrite
from scratch.
Ah well, bye for now,
Jamie.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |