![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
> Because nothing else will come along with a nice SDL like POV has.
> Almost all other raytracers *require* you to use an external mesh
> modeller to generate your scene - POV doesn't which IMO is its strongest
> point.
That, and excellent procedural textures, is why I'm interested in it. :-)
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 14-1-2010 2:16, nemesis wrote:
> andrel wrote:
>>> I think is that ATM GPU's are useful for trangulations and
>>> that the result is near real life. As far as I have heard the
>>> rendering is less physical correct and more is faked. I though they
>>> were a bit lacking in multiple reflection and refraction, in media
>>> and possibly also in versatility of procedural textures. I am not a
>>> gamer, so I don't actually know for sure.
>>>
>> So, point me to where I talked exclusively about game tech.
>
> "less physical correct", "lacking reflection and refraction", "lacking
> media" and "lacking procedural textures" are all indeed game tech
> limitations (for now)
Probably, yet going from that to the converse is a logical fallacy.
> that don't show up at all in the "physically
> correct" path tracer running on GPU I linked to.
How do you know?
>> But let me try to explain again: what you pointed at and other things
>> I have seen so far is that GPUs are used for a limited set of
>> primitives only, modelling a subset of physical behaviour. Even if
>> they claim to be physically accurate in practice they aren't
>
> GPU's don't claim anything. General purpose algorithms making use of
> their sheer math processing power do.
To be even more pedantic: it is the people that write software who claim
things.
> I thought by physically correct you were talking about materials or
> light propagation behavior, not every model being made of from polygons.
No I made both statements: they are less physical correct and don't
support all primitives of POV. Until both problems are solved it is not
sensible to try to port POV to a GPU.
>> Again what I have seen and understood is that up till now POV is more
>> physical complete (disclaimer: I have not seen everything that is out
>> there.). Hence POV still has a place.
>
> and I hope that place is a GPU.
Why? I mean why a GPU especially? There is a lot going on and I don't
see a reason to single out GPUs. I want my ray tracer to run as facst as
possible, I don't really care on what hardware it is implemented, as
long as it is affordable.
>> In order to get more 'realistic' games the GPUs have been optimized to
>> render textures and fake reflections and shadows. They can be used as
>> FPU replacement for certain tasks, but they are not perfect for
>> general processing (yet). That is as far as I know. There may have
>> been significant advances that I have missed because I am not a gamer
>> and hence do not follow the developments closely.
>
> I'm not talking about games at all.
Good, me neither.
> I only hinted at the fact that
> several other raytracers are beginning to use the GPU for their
> calculations, including full raytraced reflections, refractions,
> mesh-based lighting etc. They are not using the GPU as a mere game
> scanline engine, they are just general purpose programs (actually,
> parts of it) running on GPU.
I fail to see why it is necessary to repeat what I already indicated to
know. Has the fact that I don't share your conclusion something to do
with it? If that is the main reason, my estimate is that if you just
repeat yourself, I am not going to change my opinion.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 14-1-2010 16:54, nemesis wrote:
>>> dear. ;)
>>
> sweetie.
>
> darling.
It is a good practice on the internet to assume that anyone that has a
female sounding name is in fact an overweight 70 YO male.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel escreveu:
> On 14-1-2010 16:54, nemesis wrote:
>>>> dear. ;)
>>>
>> sweetie.
>>
>> darling.
>
> It is a good practice on the internet to assume that anyone that has a
> female sounding name is in fact an overweight 70 YO male.
Yes, caught off guard! :P
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
andrel escreveu:
> On 14-1-2010 2:16, nemesis wrote:
>> andrel wrote:
>>>> I think is that ATM GPU's are useful for trangulations and
>>>> that the result is near real life. As far as I have heard the
>>>> rendering is less physical correct and more is faked. I though they
>>>> were a bit lacking in multiple reflection and refraction, in media
>>>> and possibly also in versatility of procedural textures. I am not a
>>>> gamer, so I don't actually know for sure.
>>>>
>>> So, point me to where I talked exclusively about game tech.
>>
>> "less physical correct", "lacking reflection and refraction", "lacking
>> media" and "lacking procedural textures" are all indeed game tech
>> limitations (for now)
>
> Probably, yet going from that to the converse is a logical fallacy.
>
>> that don't show up at all in the "physically correct" path tracer
>> running on GPU I linked to.
>
> How do you know?
I know because the code is available and it implements a
general-purpose, though limited, version of a physically-based path
tracer on the GPU. No scanline trickery, just general-purpose
raytracing tapping that awesome hidden power sitting idle on your PC
right now.
> To be even more pedantic: it is the people that write software who claim
> things.
You can look at the code if you have any such understanding. If you
don't understand, you can also simply look at the video and marvel at
the physically correct reflections, caustics, soft shadows, diffuse
interreflections etc.
>> I thought by physically correct you were talking about materials or
>> light propagation behavior, not every model being made of from polygons.
>
> No I made both statements: they are less physical correct and don't
> support all primitives of POV. Until both problems are solved it is not
> sensible to try to port POV to a GPU.
A path tracer sports physically correct rendering, with full light
transport phenomena and material settings according to physics equation.
If that can run on GPU, a simple raytracer with artistic parameters
can too.
> Why? I mean why a GPU especially? There is a lot going on and I don't
> see a reason to single out GPUs. I want my ray tracer to run as facst as
> possible, I don't really care on what hardware it is implemented, as
> long as it is affordable.
Because a GPU is damned fast for math calculations and if you're not a
gamer (only such application for it now) you don't use all that awesome
power at all despite being available in every PC.
>> I'm not talking about games at all.
>
> Good, me neither.
Then I think you just don't understand the matter.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> Sabrina Kilian escreveu:
>> nemesis wrote:
>> Right, they bring a dramatic speed increase to other systems and
>> programs, so you THINK they will here as well. Prove it, or wait.
>
> I would think pov-ray's triangle handling to be similar to that of other
> raytracers but if that's not the case, I'll just wait for your word on
> it, sweetie.
How do you suggest that the ray-tracing part separates the object that
it intersects? Without a complete overhaul, it will have to support all
of the objects that POV-Ray supports. Otherwise, you have to decide at
the time the ray hits an object whether you process that on the GPU or
CPU. Then, what do you gain by offloading just the triangle and sphere
code to the GPU?
>> Depends on the card, again. If the card is only offering double or
>> triple the FLOPs of the FPU/CPU, then the speed loss by faking it in
>> software will not be better. Wide range of hardware, remember?
>
> Wide range of hardware has never prevented povray running on low-end
> hardware or super-duper minicomputers. Users never complained of the
> vastly different speeds.
Super computers are not in the same hands as higher end video cards. The
range of cards that run GPGPU type code is pretty staggering compared to
the range of CPUs on the market right now. You trust the compilers and
alpha libraries to work properly, I do not.
> So you'll be targetting CUDA? It's not cross-platform as OpenCL,
> although much more mature for now.
I will be shooting for either one, depending on which I like the syntax
of better. And which one is better documented. CUDA is mature, I have an
available card and several people with different cards available to test
on. OpenCL would be better for the long term, but a quick look over some
specs suggested that OpenCL might not be able to take advantage of the
shared system memory.
More memory, less chance to see the memory bound errors on my alpha
code. And then reducing that available resource in chucks will let me
start seeing where I can make other improvements.
>> If you happen to have a computer with a high end GPU that I can run
>> comparison benchmarks on, great. Otherwise, my development time will be
>> limited to how often I can ship code off to friends and get benchmarks
>> and profiles.
>
> sadly, I'm already an old wig with a Q6600 and a cheap nvidia card (9400
> GT if I remember correctly).
Perfect, that card has even fewer stream processors than mine; You just
volunteered.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> A path tracer sports physically correct rendering,
Well, maybe "closer to physically correct rendering". Let me know when you
have a ray tracer that supports creating diffraction gratings without cheating.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Sabrina Kilian wrote:
> How do you suggest that the ray-tracing part separates the object that
> it intersects? Without a complete overhaul, it will have to support all
> of the objects that POV-Ray supports. Otherwise, you have to decide at
> the time the ray hits an object whether you process that on the GPU or
> CPU. Then, what do you gain by offloading just the triangle and sphere
> code to the GPU?
How about this: a -gpu flag to povray? People turn it on when they
want to indicate a complete mesh-only scene to be run on GPU. The
parser then simply ignores whatever other povray primitives are there.
> Perfect, that card has even fewer stream processors than mine; You just
> volunteered.
Then I'll be glad to help. Just tell me wherever setups or installs I
need to do when you're ready.
now tell me: please say you're a hottie german blondie and not a fat
old fart! :D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> nemesis wrote:
>> A path tracer sports physically correct rendering,
>
> Well, maybe "closer to physically correct rendering".
yes. In any case, I was pointing to andrel is that it's using the GPU
power to raytrace with a typical raytracing algorithm, not using any
fake scanline game tech.
> Let me know when
> you have a ray tracer that supports creating diffraction gratings
> without cheating.
perhaps this:
http://en.wikipedia.org/wiki/Photon_tracing
the most realistic render ever:
http://www.cpjava.net/soupImages/soup_one.png
took 100 Sun SparcStation1s 1 month back in 1991 to generate the most
expensive (but beautiful) cornell box of sorts ever! :D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> nemesis wrote:
> > A path tracer sports physically correct rendering,
> Well, maybe "closer to physically correct rendering". Let me know when you
> have a ray tracer that supports creating diffraction gratings without cheating.
I won't consider a renderer "physically correct" until you create a
scene to replicate the double-slit experiment and the renderer gives the
correct image.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |