 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> which is why I'm suggesting looking only at this tiny part for the change.
> Tiny or not, it's 90% more useful for general 3D artists than all perfect
> spheres or math surfaces.
Sure, which is why there are loads of triangle-only raytracers out there
with all sorts of fancy options and rendering techniques. This is not what
POV is though.
> Would you not enjoy povray to go wildly popular? Do you prefer it to be
> this geek niche? Popularity would also bring more contributing
> developers, I guess...
Yes, I think most of us here prefer it being the only niche raytracer with
support for such a good SDL (scripting, primitives, texturing etc). I think
everyone would be sad if POV was overrun by new developers who just wanted
mesh tracing speed, POV and SDL would get lost in the sea of
mesh-tracing-clones out there.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen escreveu:
> It is and Vanessa is too. Did you know that Vanessa was coined by
> Jonathan Swift who wrote Gulliver's Travels?
Thanks. Yes, I've searched for the meaning already. Mine comes from
the Lionheart King. :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sabrina Kilian escreveu:
> nemesis wrote:
>> http://www.myspace.com/cannibalporn
>>
>> ZOMG, your teh cute! :D
>>
>>
>> kiddin... ^^;
>
> Just a few years back, the only Sabrina Kilian on google was a russian
> ice skater. Now, wow, my name has become popular.
>
> But no, not me.
yes, I guessed that emo doll wouldn't likely be you. :)
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> So that means povray will be the slowest raytracer around, is that
> right? Good Lord, it's sad that 3.7 is not out yet and it was once one
> of the fastest and first raytracers to go multicore... now it's being
> beaten by unbiased renderers!
I can't recall POV-Ray ever being one of the fastest raytracers around.
Everyone else is willing to make sacrifices concerning accuracy in
order to speed up rendering (for instance, only accepting triangles).
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Anyway, the best we can hope for is a continuation of POV along the
> lines that we are currently following.
No, the best we can hope for is the introduction of heterogenous arrays
of processors whith automatic load balancing and sharing.
Such processors would automatically vectorize the code run on them when
appropriate; in other words, programs wouldn't need to be rewritten to
use new libraries, they would just run faster.
It's a similar concept to how out of order execution works; the
processor examines the code, rearranges it and sends it to the various
processing units as appropriate.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
These four criteria have yet to be met:
GPU acceleration will be useful when the following conditions are met:
1) Support for sophisticated branching
2) Full double-precision accuracy
3) Large memory sets (other than textures)
4) Independent shaders running on distinct units.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers escreveu:
> I can't recall POV-Ray ever being one of the fastest raytracers around.
I can recall it being used as a useful benchmarking tool once it got
multicore.
> Everyone else is willing to make sacrifices concerning accuracy in
> order to speed up rendering (for instance, only accepting triangles).
If you use so many triangles so that each are smaller than a screen
pixel, you lose no more accuracy than any pov primitive.
In any cases, you get it wrong: the amazing speed up is not due to
native GPU triangle handling, but faster ray intersection calculations
thanks to the GPU sheer parallel vector processing. You can see that in
smallptGPU where you get perfect math spheres much faster, no meshes in
sight.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> 1) Support for sophisticated branching
When this happens, the GPU will be exactly the same speed as the CPU.
The GPU is fast *because* it doesn't support sophisticated branching.
> 2) Full double-precision accuracy
This already exists apparently. (E.g., my GPU supports double-precision
math.)
> 3) Large memory sets (other than textures)
My GPU has access to just under 1GB of RAM. How much do you want?
> 4) Independent shaders running on distinct units.
What exactly do you mean by that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> In any cases, you get it wrong: the amazing speed up is not due to
> native GPU triangle handling, but faster ray intersection calculations
> thanks to the GPU sheer parallel vector processing. You can see that in
> smallptGPU where you get perfect math spheres much faster, no meshes in
> sight.
>
Spheres are the other special, easy, case. Any ray that comes within
-radius- of -center point- must intersect the sphere, with a surface
normal that is pretty easy to compute. From that, the diffuse,
reflection, and so on. The math, as obvious by the very short
intersection code in smallpt, is easy and compact.
Now, for any given cone, with arbitrary rotation and ratio of base to
height, provide a fast general case for the ray intersection test, that
will give you the same information. Single test, just to be clear, not
separate cases for the disc bottom and cone top.
Then cube, then spline lathe, SOR, blobs . . .
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Chambers wrote:
>> 3) Large memory sets (other than textures)
>
> My GPU has access to just under 1GB of RAM. How much do you want?
>
They lack virtual ram in a simple sense, last I looked, but you can
manage that by having your CPU thread move things around as needed.
Messy and annoying, when the CPU gives you just under 4 gigs in a simple
32-bit OS as long as the system has the virtual ram space available. And
even more than that in 64-bit, if you ask the OS nicely. On the CPU,
when you need different parts of that 4 gigs of stuff, the OS handles
it. I suspect that, should the GPU need new data fed into memory, it
would require more than just stalling the threads while the data is
moved from ram or paged memory over to the graphics card.
>> 4) Independent shaders running on distinct units.
>
> What exactly do you mean by that?
I am guessing that he meant the ability to run multiple threads on the
GPU, instead of running 100 instances of the same thread with slightly
different starting conditions. I know that my card supports 4 different
work groups, split over 8 'processors' each.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
