 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> It was a hint for possible improvement.
Except it's a "hint" that comes up every six months, and people have told
you this, and why and how it's inapplicable to POV-Ray.
Yet you continue to put down the work of all the good people donating their
time and dismissing it because it's not a production-quality version of the
academic research project just now becoming usable on high-end graphics
hardware. You dismiss all the things that set POV-Ray apart as unimportant
and want other people to work for free to make it do the same things that
commercial systems do, and nothing more.
Again and again, you insult the work of the people actually making the
software that's self-admittedly beyond your ability to understand or
contribute to.
Are you really not seeing why everyone is bashing you? Here's a hint for a
possible improvement: don't be a dick.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Just about as much as using povray to do anything other than abstract
> math.
Sorry, I just feel that hardly anyone simply uses POV for rendering an
imported triangle mesh without any of POV's features (procedural textures,
primitives and CSG, media, etc). In fact you can see this if you look at
the HOF or the images binary group on this news server.
In short, what you suggest would have no benefit for the majority of people
here, and it would be completely pointless as other software already exists
that does what you are suggesting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 19 Jan 2010 03:28:00 -0200, nemesis wrote:
> It was a hint for possible improvement.
Not really, no - it's been an ongoing obsession of yours, even in light
(pun not intended) of countless people who know a lot more about how the
software works patiently explaining why it's not practical.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospam com> wrote:
> On Tue, 19 Jan 2010 03:28:00 -0200, nemesis wrote:
>
> > It was a hint for possible improvement.
>
> Not really, no - it's been an ongoing obsession of yours, even in light
> (pun not intended) of countless people who know a lot more about how the
> software works patiently explaining why it's not practical.
The only explanation so far being thrown has been: "we don't want to speed up
povray's ray-triangle intersections because it would make it much more useful to
people outside our small geek niche and those people wouldn't be interested in
using other povray features thus making us feel unloved". Really, they can't
stop talking how isosurfaces, textures and whatsoever would not be
well-supported on GPU even though I agreed with that from the start and only
hinted at triangles speed up.
It's not an obsession for me, it's a nostalgic feeling to see povray yet again
as king of the hill of free raytracers out there. It seems to be just nostalgia
really, that time has passed never to return.
sorry, can't help being a dick: it's a common diminutive for my first name
anyway...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> The only explanation so far being thrown has been: "we don't want to speed up
> povray's ray-triangle intersections because it would make it much more useful to
> people outside our small geek niche and those people wouldn't be interested in
> using other povray features thus making us feel unloved".
Yes, that's exactly what people have been saying.
Btw, you keep saying that the GPU could be used to speed up ray-triangle
intersection calculations, but what do you base this on?
Raytracers, including POV-Ray, use complex container structures to speed up
ray-triangle intersection calculations (such as octrees or b-trees). This
means that calculating the intersection of a ray and a triangle mesh is
much faster than linear (with respect to the number of triangles). With
most implementations the intersection routine is probably on the order
of O(log n) with respect to the amount of triangles.
How can the GPU be used to speed this up? AFAIK when rendering in the
normal way, GPUs do not prune triangles like that, but instead all you
send the GPU to render is splashed into the screen as-is. The z-buffer
can be used to avoid texturing/lighting/shader calculations on hidden parts
of triangles, but nevertheless *every single triangle* is projected onto
the screen (or, more precisely, rendered onto the z-buffer).
That's one of the reasons why game engines exist in the first place: You
can't send the entire scene to the GPU to be rendered. It would choke. The
game engine prunes the scene to its bare minimum by removing hidden surfaces
(as well as it can) before sending it to the GPU to render. Optimally only
those triangles are sent to the GPU which end up affecting the display
(although in practice getting the optimal result is next to impossible,
at least in real-time, but game engines try to get as close as possible).
Thus much of the pruning is done by the CPU, before the GPU gets to
render anything.
Now, would you kindly explain to me how the GPU can be used to speed up
ray-triangle intersections of a scene with millions of triangles in a
raytracer?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> Btw, you keep saying that the GPU could be used to speed up
ray-triangle
> intersection calculations, but what do you base this on?
Other people works like those I linked to?
> Raytracers, including POV-Ray, use complex container structures to
speed up
> ray-triangle intersection calculations (such as octrees or b-trees).
>
> How can the GPU be used to speed this up? AFAIK when rendering in the
> normal way, GPUs do not prune triangles like that, but instead all you
> send the GPU to render is splashed into the screen as-is.
You're thinking of the GPU as solely a game engine, not a programatic
processor.
> Now, would you kindly explain to me how the GPU can be used to speed up
> ray-triangle intersections of a scene with millions of triangles in a
> raytracer?
I'm sure you know Google, but out of the top of my head:
http://ompf.org/forum/viewforum.php?f=16
http://davibu.interfree.it/opencl/smallluxgpu/smallluxGPU.html
last one is implementing precisely ray-triangle intersections on GPU and
btrees as containers. Source code is GPL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis escreveu:
> I'm sure you know Google, but out of the top of my head:
> http://ompf.org/forum/viewforum.php?f=16
> http://davibu.interfree.it/opencl/smallluxgpu/smallluxGPU.html
>
> last one is implementing precisely ray-triangle intersections on GPU and
> btrees as containers.
BVH to be more precise.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> I'm sure you know Google, but out of the top of my head:
> http://ompf.org/forum/viewforum.php?f=16
> http://davibu.interfree.it/opencl/smallluxgpu/smallluxGPU.html
> last one is implementing precisely ray-triangle intersections on GPU and
> btrees as containers. Source code is GPL.
Well, since the code is ready, go ahead and integrate it in POV-Ray,
rather than whining about it. It's not like POV-Ray is closed-source.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> I'm sure you know Google, but out of the top of my head:
> http://ompf.org/forum/viewforum.php?f=16
> http://davibu.interfree.it/opencl/smallluxgpu/smallluxGPU.html
Funny, you mentioning using google when you seem to have ignored the
suggestion when I bring it up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 19 Jan 2010 13:35:47 -0500, nemesis wrote:
> The only explanation so far being thrown has been: "we don't want to
> speed up povray's ray-triangle intersections because it would make it
> much more useful to people outside our small geek niche and those people
> wouldn't be interested in using other povray features thus making us
> feel unloved".
Huh, you and I are reading different messages, then.
> Really, they can't stop talking how isosurfaces,
> textures and whatsoever would not be well-supported on GPU even though I
> agreed with that from the start and only hinted at triangles speed up.
And given the relatively small niche in the userbase who has hardware
that could do so, it doesn't seem reasonable to you to say "this is not a
good use of our developer's time"?
In any development project, there are good ideas that get put off or not
implemented due to resource constraints. This is one of those times.
Maybe the right kind of GPU hardware will become more pervasive and
someone will take this on, but until then, you'll just have to be
satisfied with the answer that's been given, which I'm quite *sure* isn't
"we want to keep the software slow", as you seem to think it is.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
