Now the normal calculation takes into account and averages 5 normal vectors
(which don't seem to be sufficient) in the area around every object.
Added the possibility to define a grayscale map which controls the
interpolation between two different textures for every object.
In this example 1000 spheres are placed with no probability map but with a
texture map (a simple gradient x, but it may be an image map as well), while
1000 cylinders are placed following a checker pattern and with a texture map
(a simple gradient z).
Who wants the code (not finished yet) can e-mail me.
I'm having an exam on thursday so I won't go on with this macro next week.

Cheers,
jrg.

Post a reply to this message

Attachments:
Download 'clutter7.jpg' (126 KB)

Preview of image 'clutter7.jpg'

JRG wrote:
> 
> Now the normal calculation takes into account and averages 5 normal vectors
> (which don't seem to be sufficient) in the area around every object.

Don't seem to be sufficient for what?  It works
perfectly for what it does.  It would be nice to use
both otions you've tried from one point to the 5 here. 
If you're trying to simulate trees or something, just
normalize the angles as straight "up" (toward the SUN)-
and maybe randomize the angle a little bit from there-
that's how they seem grow, they don't concern
themselves with the angle of the surface, just the
angle of the sun.

> Added the possibility to define a grayscale map which controls the
> interpolation between two different textures for every object.
> In this example 1000 spheres are placed with no probability map but with a
> texture map (a simple gradient x, but it may be an image map as well), while
> 1000 cylinders are placed following a checker pattern and with a texture map
> (a simple gradient z).
> Who wants the code (not finished yet) can e-mail me.
> I'm having an exam on thursday so I won't go on with this macro next week.

Exam or macro... which is really more important!?

-peter

-- 
http://www.users.qwest.net/~dearmad
Why bother?  I'm not interesting.
But... maybe "Ballet pour ma fille" will be.

Post a reply to this message

Have you thought about constructing a GREEBLE(sp?) macro for POV.  3d
Studio has now and it would ease the modeling of tiny details in
cities/machines/whatever.  Maybe it might work like a cross between your
macro, the cityscape macro, and the pipes macro.

	If you don't know what greeble is, it's the leftover junk that model
shops like ILM add to their models to detail them and add a level of
realism and scale.  The macro would really ease constructing a planet,
because you could give it a few parameters and simple models and BAM the
terrain is covered with cities, farms, ports, etc.  And the level of
detail can be reduced the farther the camera is away from the object.

Anyway, whaddya think?

Post a reply to this message

JRG schrieb:

> Now the normal calculation takes into account and averages 5 normal vectors
> (which don't seem to be sufficient) in the area around every object.
> Added the possibility to define a grayscale map which controls the
> interpolation between two different textures for every object.

Stunning... just to imagine this macro's potential for naturalistic landscapes
with vegetation and buildings!

See you in Khyberspace!
http://www.geocities.com/electricafghan/index-e.html

Yadgar

Post a reply to this message

It seems cool. I will consider the idea after my exam (phisics is a
nightmare...)

"Ben Birdsey" <cla### [at] mailcom> ha scritto nel messaggio
news:3B49FB94.31049BD5@mail.com...
>
> Have you thought about constructing a GREEBLE(sp?) macro for POV.  3d
> Studio has now and it would ease the modeling of tiny details in
> cities/machines/whatever.  Maybe it might work like a cross between your
> macro, the cityscape macro, and the pipes macro.
>
> If you don't know what greeble is, it's the leftover junk that model
> shops like ILM add to their models to detail them and add a level of
> realism and scale.  The macro would really ease constructing a planet,
> because you could give it a few parameters and simple models and BAM the
> terrain is covered with cities, farms, ports, etc.  And the level of
> detail can be reduced the farther the camera is away from the object.
>
> Anyway, whaddya think?

Post a reply to this message

JRG wrote:
> 
> Now the normal calculation takes into account and averages 5 normal vectors
> (which don't seem to be sufficient) in the area around every object.
> Added the possibility to define a grayscale map which controls the
> interpolation between two different textures for every object.
> In this example 1000 spheres are placed with no probability map but with a
> texture map (a simple gradient x, but it may be an image map as well), while
> 1000 cylinders are placed following a checker pattern and with a texture map
> (a simple gradient z).
> Who wants the code (not finished yet) can e-mail me.

This is really getting along.

I would suggest to put it on a website when finished, together with some
documentation and samples, this looks like a very useful macro, even for
new users. 

> I'm having an exam on thursday so I won't go on with this macro next week.
> 

Good luck!

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Now, to say the truth, I'm stuck in a problem that seems a bug to me.
Trace() often doesn't work well with isosurfaces (every normal vector is
stored as <0,0,0> even if intersection occurs).
Or, better, sometimes it works fine like it should and sometimes it
completely fails. This happens only with isosurface landscape.
It's really a puzzle...

jrg.
"Christoph Hormann" <chr### [at] gmxde> ha scritto nel messaggio
news:3B4B055C.BB12F72A@gmx.de...
>
>
> JRG wrote:
> >
> > Now the normal calculation takes into account and averages 5 normal
vectors
> > (which don't seem to be sufficient) in the area around every object.
> > Added the possibility to define a grayscale map which controls the
> > interpolation between two different textures for every object.
> > In this example 1000 spheres are placed with no probability map but with
a
> > texture map (a simple gradient x, but it may be an image map as well),
while
> > 1000 cylinders are placed following a checker pattern and with a texture
map
> > (a simple gradient z).
> > Who wants the code (not finished yet) can e-mail me.
>
> This is really getting along.
>
> I would suggest to put it on a website when finished, together with some
> documentation and samples, this looks like a very useful macro, even for
> new users.
>
> > I'm having an exam on thursday so I won't go on with this macro next
week.
> >
>
> Good luck!
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

JRG wrote:
> 
> Now, to say the truth, I'm stuck in a problem that seems a bug to me.
> Trace() often doesn't work well with isosurfaces (every normal vector is
> stored as <0,0,0> even if intersection occurs).
> Or, better, sometimes it works fine like it should and sometimes it
> completely fails. This happens only with isosurface landscape.
> It's really a puzzle...
> 

This is a known problem, Megapov's isosurface code seems to be buggy in
that matter.  Funnily it seems to differ depending on whether you use a
freshly started program instance or render it a second time...

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Yes, that's the problem! It's really strange...

"Christoph Hormann" <chr### [at] gmxde> ha scritto nel messaggio
news:3B4B5D24.3FAF822B@gmx.de...
>
>
> JRG wrote:
> >
> > Now, to say the truth, I'm stuck in a problem that seems a bug to me.
> > Trace() often doesn't work well with isosurfaces (every normal vector is
> > stored as <0,0,0> even if intersection occurs).
> > Or, better, sometimes it works fine like it should and sometimes it
> > completely fails. This happens only with isosurface landscape.
> > It's really a puzzle...
> >
>
> This is a known problem, Megapov's isosurface code seems to be buggy in
> that matter.  Funnily it seems to differ depending on whether you use a
> freshly started program instance or render it a second time...
>
> Christoph
>
> --
> Christoph Hormann <chr### [at] gmxde>
> IsoWood include, radiosity tutorial, TransSkin and other
> things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:



> JRG wrote:
>> 
>> Now, to say the truth, I'm stuck in a problem that seems a bug to me.
>> Trace() often doesn't work well with isosurfaces (every normal vector is
>> stored as <0,0,0> even if intersection occurs).
>> Or, better, sometimes it works fine like it should and sometimes it
>> completely fails. This happens only with isosurface landscape.
>> It's really a puzzle...
>> 

> This is a known problem, Megapov's isosurface code seems to be buggy in
> that matter.  Funnily it seems to differ depending on whether you use a
> freshly started program instance or render it a second time...

Sounds like memory corruption.  I've got the same problem with the mesh
code.  It's very very strange.  First run, fine, second one will crash.

And it's holding up my simulation patch! :(

Geoff

Post a reply to this message