"PM 2Ring" <nomail@nomail> wrote:
> povray <pov### [at] almostbestwebnet> wrote:
> > PM 2Ring wrote:
> > > This group of stones is a single isosurface.

> > Is there a particular reason you desired to make all the stones
> > one isosurface?  it seems like you'd get a faster render time if
> > they were seperate objects.

>  isosurfaces can be faster than you might think. I have a sofa object
> derived from one of Jaime's LightSys demo scenes. The original is built
> from isosurface{f_rounded_box()}, I converted it to use superellipsoids,
> but the isosurface version was the faster! IIRC, I posted the scene file in
> p.b.i a couple of weeks ago; look for the very shiny blue sofa.

Here it is:  <web.4315a37135b6ce9d60c4f6d10@news.povray.org>

Time it for yourself.

Post a reply to this message

PM 2Ring wrote:
>
> Thanks, Thomas. If a geologist likes my stones, they must be good! :)
>

OT, but bumped to mind of this line...

"Everyone, let's thank Thomas"
"Thank you Thomas"

What movie?

Follow-ups to OT...

-- 
Eero "Aero" Ahonen
    http://www.zbxt.net
       aer### [at] removethiszbxtnetinvalid

Post a reply to this message

As someone else said your IsoStones are very instructive - thanks for
posting the source.

The stone textures - in fact most of the old 3.1 textures - have never been
updated to account for the resulting image being gamma corrected. The 3.1
stone textures for example were to be rendered with an assumed gamma of 2.2.
The automatic portfolio set up INGO put together rendered them with an
assumed gamma of 1.0 just as you too used them. However, used in this way
all these textures will appear washed out compared to the creators intent.

For good reasons we should be using the assumed gamma of 1.0 for renders,
but the majority of the sample textures look washed out if you do it. Leads
to some confusion I think - it certainly confused me for a time.

A_stones.jpg  is my render of your original source using 3.6.

B_stones.jpg uses the assumed gamma of 2.2 so the stones look as they did in
3.1, but naturally the sand and lighting is darker than you intended because
no gamma correction was done - my display gamma is set to 2.2 as is true for
most PC users (1).

C_stones.jpg takes a stab at un-gamma correcting the stone textures so that
when the gamma correction is done the stones appear as I think intended by
the texture creators, but with your lighting and sand color.

(1) - Most all PC displays have a display gamma of about 2.2 except for
Apple, SGI and perhaps a few other less common platforms.


"PM 2Ring" <nomail@nomail> wrote in message
news:web.43283a638195286505e02d50@news.povray.org...
> "Nathan Kopp" <pov### [at] nkoppmailshellcom> wrote:
> > I never knew that the standard stone textures could look so realistic!
....
> Speaking of Jaime, since reading the LightSys docs I've been seriously
> thinking of updating the stones.inc textures. They don't behave well in
> radiosity scenes, due to ambient content, but what's worse, they use the
> dreaded crand, so they make horrible flying pixels in animations.
>
> These stone textures come from the bad old days, before macros, and
probably
> before pigment functions (sorry, my POV history is a little rusty at this
> hour of the morning :) so I'm sure some interesting things can be done to
> modernize these textures and make them more flexible.
>

Post a reply to this message

Attachments:
Download 'C_stones.jpg' (95 KB) Download 'A_stones.jpg' (86 KB) Download 'B_stones.jpg' (82 KB)

Preview of image 'C_stones.jpg'

Preview of image 'A_stones.jpg'

Preview of image 'B_stones.jpg'

PM 2Ring wrote:
> This group of stones is a single isosurface. The wet sand is a
> normal-perturbed plane. The stone textures are the standard textures
> in stones.inc.

This is nice work. Perhaps once you've finished with your tweaks to it you
may like to consider submitting it (or a variation thereof) for consideration
as a standard POV-Ray example scene.

-- Chris

Post a reply to this message

"PM 2Ring" <nomail@nomail> schreef in bericht
news:web.432834058195286505e02d50@news.povray.org...
> "Thomas de Groot" <t.d### [at] internlnet> wrote:
> > "PM 2Ring" <nomail@nomail> schreef in bericht
> > news:web.43242b50bddb89c077d3bc6c0@news.povray.org...
> > > This group of stones is a single isosurface. The wet sand is a
> > >
> > Very, very good!!
>
> Thanks, Thomas. If a geologist likes my stones, they must be good! :)
>
>

<grin>

Thomas

Post a reply to this message

A derivative work, hopefully okay since the SDL was shared...

Post a reply to this message

Attachments:
Download 'pm2ringstone03.png' (162 KB)

Preview of image 'pm2ringstone03.png'

PM 2Ring wrote:
> 
> Also, isosurfaces can be faster than you might think. I have a sofa object
> derived from one of Jaime's LightSys demo scenes. The original is built
> from isosurface{f_rounded_box()}, I converted it to use superellipsoids,
> but the isosurface version was the faster! IIRC, I posted the scene file in
> p.b.i a couple of weeks ago; look for the very shiny blue sofa.
> 

well, one sofa is different from many stones: completely
different from the original picture posted.

> 
>>I picture something like ... defining 12 different rock shapes.
>>Then, whenever you place a rock, randomly pick which of the 12
>>pre-defined rock shapes to place.  Rotate it randomly y before
>>placing it.  As each one is placed, randomly texture it.
> 
> 
> Sure, I can do that:). However, you don't really save memory (in the current
> version of POV) by doing this, unless you're doing it with mesh objects.

Memory was not the concern of my posting; render time was.
If I wanted many stones in a single isosurface, my poor
CPU would kick it's little feet in the air and expire.
Or at least my patience would.  :D

> For an interesting variation on this theme, see my two recent threads,
> "MultiMesh" in the General area and "Grass using MultiMesh" in p.b.i.
> 
> 

Errrrr, I can guess that "multimesh" uses MESH objects,
What does that have to do with isosurface pebbles?

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
> PM 2Ring wrote:
> > This group of stones is a single isosurface. The wet sand is a
> > normal-perturbed plane. The stone textures are the standard textures
> > in stones.inc.
>
> This is nice work. Perhaps once you've finished with your tweaks to it you
> may like to consider submitting it (or a variation thereof) for consideration
> as a standard POV-Ray example scene.

Thanks, Chris! I would be delighted to submit a variation of this scene for
consideration as a standard POV-Ray example scene. I've (almost) given up
improving the stone displacement, but I've been polishing up the code,
adding comments & better identifiers. I'll post my latest version in a day
or so, when I get the chance.

I could add a sand isosurface & maybe even a water object, but I don't want
to make the scene too complex. Besides, from my tests today, the minor
visual improvements don't justify the increased render time.

Post a reply to this message

"William Pokorny" <pok### [at] attglobalnet> wrote:
> As someone else said your IsoStones are very instructive - thanks for
> posting the source.

Thanks, William.

> The stone textures - in fact most of the old 3.1 textures - have never been
> updated to account for the resulting image being gamma corrected. The 3.1
> stone textures for example were to be rendered with an assumed gamma of 2.2.
> The automatic portfolio set up INGO put together rendered them with an
> assumed gamma of 1.0 just as you too used them. However, used in this way
> all these textures will appear washed out compared to the creators intent.

Ok.

> For good reasons we should be using the assumed gamma of 1.0 for renders,
> but the majority of the sample textures look washed out if you do it. Leads
> to some confusion I think - it certainly confused me for a time.

Me, too! I'm still easily confused about how assumed_gamma & display_gamma
work together. :)

> A_stones.jpg  is my render of your original source using 3.6.
>
> B_stones.jpg uses the assumed gamma of 2.2 so the stones look as they did in
> 3.1, but naturally the sand and lighting is darker than you intended because
> no gamma correction was done - my display gamma is set to 2.2 as is true for
> most PC users (1).
>
> C_stones.jpg takes a stab at un-gamma correcting the stone textures so that
> when the gamma correction is done the stones appear as I think intended by
> the texture creators, but with your lighting and sand color.
>
> (1) - Most all PC displays have a display gamma of about 2.2 except for
> Apple, SGI and perhaps a few other less common platforms.

This old monitor is very bright. I have the brightness as low as it can go,
but it's still a bit too bright for me. I have set my Display_Gamma to 2.6,
but I think I should re-calibrate it. All my images look too bright on
other peoples' monitors & my lcd monitor at work.

At first, this didn't worry me, as I've seen some fantastic pictures here
that were using gamma 2.2 that were so dark I had to gamma-correct them to
view them. Fortunately, my video card lets me do this pretty easily.

Your picture C looks too dark to me, B is just right. As I said, I've got to
do something about this monitor. :)

Post a reply to this message

"Greg M. Johnson" <gregj;-)565### [at] aolcom> wrote:
> A derivative work, hopefully okay since the SDL was shared...

Sure! But you don't need to make the text quite so big, Greg. :)

I tried putting a mandelbrot onto a stone, but it looked ugly.

Post a reply to this message