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

Geoff Wedig wrote:
> 
> 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.
> 

IIRC that isosurface problem is caused by some missing initializations in
the MP isosurface code.  There is not much use in trying to fix it since
there will be a complete rewrite of that functions in Povray 3.5.

I don't know about any similar problem with meshes, their code is also
quite old and well tested.

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

What simulation patch, did you post something about it before?

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

With my macro, it seems that adding method 1 solves the problem (dunno why).

"Christoph Hormann" <chr### [at] gmxde> ha scritto nel messaggio
news:3B4### [at] gmxde...
>
>
> Geoff Wedig wrote:
> >
> > 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.
> >
>
> IIRC that isosurface problem is caused by some missing initializations in
> the MP isosurface code.  There is not much use in trying to fix it since
> there will be a complete rewrite of that functions in Povray 3.5.
>
> I don't know about any similar problem with meshes, their code is also
> quite old and well tested.
>
> > And it's holding up my simulation patch! :(
> >
>
> What simulation patch, did you post something about it before?
>
> 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

Ben Birdsey wrote:

>         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?

Man, I'de love a greeble macro.  Instant hull plating for space ships,
instant death star, etc.  Been tring on and off for years to write one
and was never able to get good results.

BTW, thanks for explaining where the term "greeble" came from.
I'de read it in the "Star Wars Sketchbook" (back when there was
only one Star Wars movie) and never knew where it came from.

Pete

Post a reply to this message