 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi there. I'm new to POV-ray and i'm really enthusiastic about it. I have some
questions to ask :
1.) I have noticed that when i make a plane with a chess pattern, the further
the camera looks, the more rumbled the plane becomes. Is there any way to avoid
it ? ( even with AA on things don't change much )
2.) Could GPUs be used in order to accelerate part or the whole of the
processing intentsive calculations of the ray-tracing process ( GPGPU )
3.) Antialising in POVray - correct me if i'm wrong - is done in software and
thus resulting in alot of added time. Is it possible to let the GPU do this
task as all modern GPUs have specialized hardware to do this ?
4.) Does POV-ray uses the the SSE ( 1/2/3/4/4.1 ) instructions sets ?
5.) is POV-ray capable of caustics ?
I'm a newbie to pov-ray so some of these questions may sound silly or stupid, so
please bear with me :-)
thank you in advance
E.T.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
E.T. <nomail@nomail> wrote:
> 1.) I have noticed that when i make a plane with a chess pattern, the further
> the camera looks, the more rumbled the plane becomes. Is there any way to avoid
> it ? ( even with AA on things don't change much )
You can bump up antialiasing settings (eg. +a0.0 +am2) but you will never
completely get rid of those artifacts. It's one problem with procedural
textures.
> 2.) Could GPUs be used in order to accelerate part or the whole of the
> processing intentsive calculations of the ray-tracing process ( GPGPU )
Not really.
> 3.) Antialising in POVray - correct me if i'm wrong - is done in software and
> thus resulting in alot of added time. Is it possible to let the GPU do this
> task as all modern GPUs have specialized hardware to do this ?
No.
> 4.) Does POV-ray uses the the SSE ( 1/2/3/4/4.1 ) instructions sets ?
As far as the used C++ compiler supports creating SSE instructions.
Some binaries are compiled in such way.
> 5.) is POV-ray capable of caustics ?
Yes. http://povray.org/documentation/view/3.6.1/424/
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> E.T. <nomail@nomail> wrote:
> > 1.) I have noticed that when i make a plane with a chess pattern, the further
> > the camera looks, the more rumbled the plane becomes. Is there any way to avoid
> > it ? ( even with AA on things don't change much )
>
> You can bump up antialiasing settings (eg. +a0.0 +am2) but you will never
> completely get rid of those artifacts. It's one problem with procedural
> textures.
>
> > 2.) Could GPUs be used in order to accelerate part or the whole of the
> > processing intentsive calculations of the ray-tracing process ( GPGPU )
>
> Not really.
>
> > 3.) Antialising in POVray - correct me if i'm wrong - is done in software and
> > thus resulting in alot of added time. Is it possible to let the GPU do this
> > task as all modern GPUs have specialized hardware to do this ?
>
> No.
>
> > 4.) Does POV-ray uses the the SSE ( 1/2/3/4/4.1 ) instructions sets ?
>
> As far as the used C++ compiler supports creating SSE instructions.
> Some binaries are compiled in such way.
>
> > 5.) is POV-ray capable of caustics ?
>
> Yes. http://povray.org/documentation/view/3.6.1/424/
>
> --
> - Warp
Thank you for your fast reply Warp, about the caustics seems i was too fast to
ask, had not reached that part of documentation yet.
Now, if i don't sound too bothering, i would like to ask 'why' on those two big
NO's ( about GPGPU and about AA on the GPU ), if that's not a huge explanation
of course.
Thanks in advance
E.T.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Now, if i don't sound too bothering, i would like to ask 'why' on those two big
> NO's ( about GPGPU and about AA on the GPU ), if that's not a huge explanation
> of course.
>
> Thanks in advance
>
> E.T.
1) since povray is portable to many OSes and there's no uniform way of doing
GPGPU stuff (yet), this is a kill criterium.
2) the GPU can only antialias what it knows, and the GPU only knows how to
render meshes and bitmap textures. Since povray doesn't normally use meshes ore
bitmap textures , the GPU wouldn't know what to antialias.
correct me if i'm wrong
greets
Aydan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Aydan napsal(a):
>> Now, if i don't sound too bothering, i would like to ask 'why' on those two big
>> NO's ( about GPGPU and about AA on the GPU ), if that's not a huge explanation
>> of course.
>>
>> Thanks in advance
>>
>> E.T.
> 1) since povray is portable to many OSes and there's no uniform way of doing
> GPGPU stuff (yet), this is a kill criterium.
>
> 2) the GPU can only antialias what it knows, and the GPU only knows how to
> render meshes and bitmap textures. Since povray doesn't normally use meshes ore
> bitmap textures , the GPU wouldn't know what to antialias.
>
> correct me if i'm wrong
>
> greets
> Aydan
>
>
another main reason is that graphics card is essentially a scanline
renerer, not raytracer. It cannot handle things like refraction and
reflection (though a planar reflection can be achieved manually via a
stencil buffer). It reduces the usage a lot.
--
the ultimate time-killer:
+a0.0 +am2 +r9
Johnny D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4821b485@news.povray.org...
> E.T. <nomail@nomail> wrote:
>> 1.) I have noticed that when i make a plane with a chess pattern, the
>> further
>> the camera looks, the more rumbled the plane becomes. Is there any way to
>> avoid
>> it ? ( even with AA on things don't change much )
>
> You can bump up antialiasing settings (eg. +a0.0 +am2) but you will never
> completely get rid of those artifacts. It's one problem with procedural
> textures.
that's not entirely true, try this:
--- start code ---
#local Camera_Location=<0,1,0>;
#local Color1=red 1;
#local Color2=blue 1;
camera {
location Camera_Location
look_at z+y
}
plane {y,0
pigment {
pigment_pattern {
spherical scale 25 translate Camera_Location*<1,1,1> color_map {[0 rgb
0][.75 rgb 1]} poly_wave 1
}
pigment_map {
[0 rgb (Color1+Color2)/2]
#local I=0;
#local MI=20;
#while (I<MI)
[I/MI
pigment_pattern {boxed translate 1 scale .5 warp {repeat x} warp
{repeat y} warp {repeat z} translate .5*y}
pigment_map {
[0 rgb (Color1+Color2)/2]
[1-(I/MI) average
pigment_map {
[1-(I/MI) rgb (Color1+Color2)/2]
[(I/MI) checker Color1 Color2]
}
]
}
]
#local I=I+1;
#end
[1 pigment_pattern {boxed translate 1 scale .5 warp {repeat x} warp
{repeat y} warp {repeat z} translate .5*y}
pigment_map {
[0 rgb (Color1+Color2)/2]
[0 checker Color1 Color2]
}
]
}
}
finish {ambient 1 diffuse 0}
}
--- end code ---
if you render this, even without anti-aliasing, you won't get any
"rumbling". (you'll have to adjust the scale of the spherical pattern for it
to look good enough to be of use)
this is a form of mipmapping (often used in scanline-renderers exactly to
solve the problem you mention) but there are some huge problems with the way
it's done here. First, it will not look good in reflections or refractions.
Second, it's not accurate: the amount of blurring only depends on the
distance from the camera, it sould also be dependant to the angle, which is
possible in MegaPOV with the aoi-pattern. See my site (Gallery ->
Experiments) for two other experiments with mipmapping in POV-Ray (actually
MegaPOV).
cu!
--
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x) // ZK http://www.povplace.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
E.T. wrote:
> Now, if i don't sound too bothering, i would like to ask 'why' on those two big
> NO's ( about GPGPU and about AA on the GPU ), if that's not a huge explanation
> of course.
The idea is actually not so far-fetched. Although the traditional
interfaces for scanline rendering (typically via OpenGL or DirectX)
are not helpful for raytracing, the processing power which is idly
adding some extra heat to your system for most application just
begs to be tapped in a more direct way.
This process is still in its infancy, yet a range of NVIDIA cards
is already programmable in C (and not just for Windows), see
http://www.nvidia.com/object/cuda_home.html
Of course, the architecture is very different from normal CPUs.
What they are really good at is massively parallel calculation
intensive stuff with few dependencies on global shared memory.
Doesn't sound too bad for offloading some raytracing duty.
But of course it would be a lot of work and it's still too
hardware specific. Wait a few years and it might just be a
further supported target platform for POV-Ray ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1.) I have noticed that when i make a plane with a chess pattern, the
> further
> the camera looks, the more rumbled the plane becomes. Is there any way to
> avoid
> it ? ( even with AA on things don't change much )
In addition to using AA, it can be good to use fog and/or focal blur to
cover for aliasing in distant textures and objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Attwood" <tim### [at] comcastnet> wrote:
> > 1.) I have noticed that when i make a plane with a chess pattern, the
> > further
> > the camera looks, the more rumbled the plane becomes. Is there any way to
> > avoid
> > it ? ( even with AA on things don't change much )
>
> In addition to using AA, it can be good to use fog and/or focal blur to
> cover for aliasing in distant textures and objects.
Guys, i'm sorry for bumping this old thread, there seems to exist some news
though. i was searching around and i found this site :
http://sio2.g0dsoft.com/modules/wmpdownloads/viewcat.php?cid=1
this guy among his demos, has 3 of them ( 8th, 9th and 10th from the top ) which
implement real time ray tracing which is done in the GPU with very decent frame
rates. The ray tracing algorithm is implemented as a pixel shader program. So
maybe it's not a far-fetched dream. On my computer ( nvidia 6600 ) i got about
13 FPS with the hardwareraytrace2 demo and about 60 fps with hardwareraytrace.
So maybe it's very possible to use the GPU and the power of their pixel shaders
in order to make pov-ray faster.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
E.T. wrote:
> this guy among his demos, has 3 of them ( 8th, 9th and 10th from the top )
> which implement real time ray tracing which is done in the GPU with very
> decent frame rates. The ray tracing algorithm is implemented as a pixel
> shader program. So maybe it's not a far-fetched dream. On my computer (
> nvidia 6600 ) i got about 13 FPS with the hardwareraytrace2 demo and about
> 60 fps with hardwareraytrace. So maybe it's very possible to use the GPU
> and the power of their pixel shaders in order to make pov-ray faster.
All that proves is that it's possible to write a raytracer (from scratch)
for a GPU, not that a GPU can be used to make POV-Ray faster. It's a
completely different task to design a raytracing algorithm to fit in the
limitations of a pixel shader, than to modify an existing (and quite
complex!) raytracer to be sped up by a GPU.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
