POV-Ray : Newsgroups : povray.binaries.images : -Another- RSOCP variation (217kB jpeg) Server Time
2 Aug 2024 18:12:04 EDT (-0400)
  -Another- RSOCP variation (217kB jpeg) (Message 11 to 20 of 22)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>
From: scott
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 09:48:34
Message: <4677deb2@news.povray.org>
> This is based on an image posted here about six months (?) ago. The 
> original
> artist may recognize that I ripped his idea off...

http://farm1.static.flickr.com/64/153557795_17d207dad0_o.jpg

Yeh I noticed, but that's the whole point of posting stuff here, so that 
everyone else can get inspiration.  It looks good :-)  Actually I got 
inspiration for my original from a promotional magazine in the office next 
to mine.

Also, I found that using superellipsoids rather than rounded boxes gave 
"smoother" looking reflections.


Post a reply to this message

From: Thomas de Groot
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 10:05:56
Message: <4677e2c4$1@news.povray.org>
"Stefan Viljoen" <spa### [at] removethispolardcom> schreef in bericht 
news:4677d9be@news.povray.org...
>
> Bedankt, Thomas! Interessant om 'n Nederlander hier te sien. Hoe se julle
> daar? Erg Leuk!
>
> Groete vir die kaaskoppe

Ja, wat zal ik zeggen? Ik moet mij toch eens wat meer in het Afrikaans 
verdiepen :-)  Lezen gaat altijd wel....

En de groeten van de kaaskop!!!  Joeghei!

Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 10:09:43
Message: <4677e3a7@news.povray.org>
"Stefan Viljoen" <spa### [at] removethispolardcom> schreef in bericht 
news:4677d933@news.povray.org...
> I'll remember that when rendering in 1280x1024 in the future.
>


There is a nice little thing you can use easily:

//before the camera definition:
#local H=image_width/sqrt(image_height*image_width);
#local V=image_height/sqrt(image_height*image_width);
#local Iwidth = 500;
#local Iheight = 600;

//in the camera definition use:
right    x*(Iwidth*M)/(Iheight*M)


Thomas


Post a reply to this message

From: Thomas de Groot
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 10:13:07
Message: <4677e473@news.povray.org>
"Thomas de Groot" <t.d### [at] internlDOTnet> schreef in bericht 
news:4677e3a7@news.povray.org...
>
> "Stefan Viljoen" <spa### [at] removethispolardcom> schreef in bericht 
> news:4677d933@news.povray.org...
>> I'll remember that when rendering in 1280x1024 in the future.
>>
>
>
> There is a nice little thing you can use easily:
>
> //before the camera definition:
> #local H=image_width/sqrt(image_height*image_width);
> #local V=image_height/sqrt(image_height*image_width);
> #local Iwidth = 500;
> #local Iheight = 600;
>
> //in the camera definition use:
> right    x*(Iwidth*M)/(Iheight*M)
>
>
> Thomas
>

Ouch!! forgot
#local M = 1;
 in the declaration. Not really essential though, but for completeness sake 
of this example.

Thomas


Post a reply to this message

From: Rune
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 10:21:20
Message: <4677e660$1@news.povray.org>
Thomas de Groot wrote:
> There is a nice little thing you can use easily:
>
> //before the camera definition:
> #local H=image_width/sqrt(image_height*image_width);
> #local V=image_height/sqrt(image_height*image_width);
> #local Iwidth = 500;
> #local Iheight = 600;
>
> //in the camera definition use:
> right    x*(Iwidth*M)/(Iheight*M)
>

> Ouch!! forgot
> #local M = 1;
> in the declaration. Not really essential though, but for completeness
> sake of this example.

I don't understand this. You declare H and V using a clever method, but then 
don't use those variables at all...

I'd simply say:

#local W = image_width/sqrt(image_height*image_width);
#local H = image_height/sqrt(image_height*image_width);

// in the camera definition use:
right    x*W
up y*H // or z*H if Z is up

Rune
-- 
http://runevision.com


Post a reply to this message

From: Stefan Viljoen
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 11:44:34
Message: <4677f9e1@news.povray.org>
scott wrote:

>> This is based on an image posted here about six months (?) ago. The
>> original
>> artist may recognize that I ripped his idea off...
> 
> http://farm1.static.flickr.com/64/153557795_17d207dad0_o.jpg
> 
> Yeh I noticed, but that's the whole point of posting stuff here, so that
> everyone else can get inspiration.

Well, your scene sure inspired me!

> It looks good :-)  Actually I got 
> inspiration for my original from a promotional magazine in the office next
> to mine.

I wonder if there are any truly original ideas around anywhere anymore...
 
> Also, I found that using superellipsoids rather than rounded boxes gave
> "smoother" looking reflections.

I simply used Moray 3.5's "standard" rounded box for my boxes - how does
rendering time compare for unions (which my boxes are) vs. superellipsoids?
-- 
Stefan


Post a reply to this message

From: "Jérôme M. Berger"
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 15:48:48
Message: <46783320$1@news.povray.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rune wrote:
> Thomas de Groot wrote:
>> There is a nice little thing you can use easily:
>>
>> //before the camera definition:
>> #local H=image_width/sqrt(image_height*image_width);
>> #local V=image_height/sqrt(image_height*image_width);
>> #local Iwidth = 500;
>> #local Iheight = 600;
>>
>> //in the camera definition use:
>> right    x*(Iwidth*M)/(Iheight*M)
>>
> 
>> Ouch!! forgot
>> #local M = 1;
>> in the declaration. Not really essential though, but for completeness
>> sake of this example.
> 
> I don't understand this. You declare H and V using a clever method, but then 
> don't use those variables at all...
> 
> I'd simply say:
> 
> #local W = image_width/sqrt(image_height*image_width);
> #local H = image_height/sqrt(image_height*image_width);
> 
> // in the camera definition use:
> right    x*W
> up y*H // or z*H if Z is up
> 
> Rune
	Why the square root? Why not simply:
up y // or z
right x * image_width / image_height

	Or
up y * image_height
right x * image_width

	The actual length of the vectors doesn't matter since he used angle
afterwards.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGeDMgd0kWM4JG3k8RAjDhAJ9PksYQGfFUh+tC5CixcH2bq7jJ5wCgnrW9
5VBHNX5QrRgPQBn3ICS0EUQ=
=zKgU
-----END PGP SIGNATURE-----


Post a reply to this message

From: Rune
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 19 Jun 2007 17:41:54
Message: <46784da2$1@news.povray.org>

> Rune wrote:
>> I'd simply say:
>>
>> #local W = image_width/sqrt(image_height*image_width);
>> #local H = image_height/sqrt(image_height*image_width);
>>
>> // in the camera definition use:
>> right    x*W
>> up y*H // or z*H if Z is up
>>
>> Rune
>
> Why the square root? Why not simply:
> up y // or z
> right x * image_width / image_height
>
> Or
> up y * image_height
> right x * image_width
>
> The actual length of the vectors doesn't matter since he used angle
> afterwards.

I screwed a bit up in my previous message. Here is what I meant:

If you want an automatic adjustment for image ratio that doesn't prioritize 
either horizontal or vertical angle, you can use:

#declare Zoom = 1.0;

up y*sqrt(image_height/image_width)/Zoom
right x*sqrt(image_width/image_height)/Zoom

This will for example have the effect that if you switch the width and 
height of the image, it will be like if you rotated a real camera 90 
degrees: the area will be the same.

Remember though that the effect will be overruled if the angle keyword is 
used.

Rune
-- 
http://runevision.com


Post a reply to this message

From: Thomas de Groot
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 20 Jun 2007 03:43:28
Message: <4678daa0@news.povray.org>
"Rune" <new### [at] runevisioncom> schreef in bericht 
news:4677e660$1@news.povray.org...
>
> I don't understand this. You declare H and V using a clever method, but 
> then don't use those variables at all...
>
Ouch!!!  You are perfectly right! I was falling asleep probably :-)
H and V have nothing to do with  this :-(
They are used for something different... Just copied stupidly a bit of code 
without really checking...

Thomas


Post a reply to this message

From: Alain
Subject: Re: -Another- RSOCP variation (217kB jpeg)
Date: 20 Jun 2007 17:41:08
Message: <46799ef4$1@news.povray.org>
Stefan Viljoen nous apporta ses lumieres en ce 2007/06/19 11:44:
> scott wrote:
> 
>>> This is based on an image posted here about six months (?) ago. The
>>> original
>>> artist may recognize that I ripped his idea off...
>> http://farm1.static.flickr.com/64/153557795_17d207dad0_o.jpg
>>
>> Yeh I noticed, but that's the whole point of posting stuff here, so that
>> everyone else can get inspiration.
> 
> Well, your scene sure inspired me!
> 
>> It looks good :-)  Actually I got 
>> inspiration for my original from a promotional magazine in the office next
>> to mine.
> 
> I wonder if there are any truly original ideas around anywhere anymore...
>  
>> Also, I found that using superellipsoids rather than rounded boxes gave
>> "smoother" looking reflections.
> 
> I simply used Moray 3.5's "standard" rounded box for my boxes - how does
> rendering time compare for unions (which my boxes are) vs. superellipsoids?
A superellipsoid takes longer to render than box, spheres and cylinders. Box and 
spheres are highly optimised shapes, and cylinders are slightly less. 
Superellipsoids can't benefit as much from optimisation as they have variable 
curvature and much more complex equations.

-- 
Alain
-------------------------------------------------
Save the whales. Collect the whole set.


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.