 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> In article <47973c65@news.povray.org>, sau### [at] netscape net says...
>> Why you say no when CPU-GPU combos are been used in several applications
>> like I listed, ray-tracing or there are trends to use this combo to
>> solve problems so I think is a yes, maybe is in very early stages but
>> this is tending to evolve and could become common ground and open
>> source. Why are you so negative about it? What would make you think in a
>> yes?
>>
> As Warp says, its not really designed for recursive raytracing. There
> **are** hybrid applications that do fairly decent results, which
> probably do use it to speed things up a bit, **however** those systems
> are intended for production level systems, where speed is considered
> more important than realism. Since POVRay's primary goal is to generate
> the more realistic physical model possible, and short cuts that could be
> used to produce a movie, or the like, by side stepping, short cutting,
> or even ignoring, certain methods, in favor of speed, are "not" the
> intended goal here. Mind you, I wouldn't mind some of those short cuts,
> since its damn near impossible to do some things the "right" way, and
> certainly not in a sane span of time. But, short of adding those in as
> optional, so those in "production" level fields could use them, while
> leaving the normal methods intact, there isn't a benefit to the intent
> of the project to do that.
I'm a quality over quantity demanding person, so this is just fine for
me, altough a speeding the rough/test/WIP/preview scenes could be very
good to improve the creativity you can achieve with POV-Ray. I would
never would want to downgrade output of POV-Ray just to speed it up with
a GPU except just for rough/test/WIP/preview.
I think could be useful to call funtions of the raytracer directly over
selected objects with local (per scene) parameter just to see the
effects of those functions and better understand them and then use the
more appropriates ones. Just a thought.
> About half the people here would scream bloody murder and try to beat
> you to death with a checker plane
LOL :) You've been ray-tracing too long when you make jokes like this,
very good one. :)
> if you tried to add shortcuts, never
> mind that there aren't a lot of free rendering systems that are as good,
> and also use those short cuts. Most of the other half would still be
> busy sharpening the edges of their triangle primitives, just in case
> your suggestion did break the physical based systems already in there.
> lol But, I think you see what I am getting at. Even if some of us would
> find it useful to take short cuts, its *not* what the program is
> supposed to be designed for, and what it *is* intended for isn't
> functionally possible in current GPUs.
I see. As I wrote, I would like this only as rough/test/WIP/preview,
specially if the rough/test/WIP/preview could be rendered fast or in
real-time. The final output is and should always be SLOW for HIGHEST
quality purposes, which I enjoy very much. Actually I enjoy rendering
POV-Ray images slowly, since version 1.0 (which I still have), since
real-time Virtual Reality renderers are impossible for most if not all
of us, getting only one frame of VR slow is just fine for me :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 24 Jan 2008 12:31:03 -0200, Nicolas Alvarez wrote:
> Jim Henderson escribió:
>>> The 286 architecture also had a 287 co-processor, but I'm not sure
>>> if
>>> it supported 64-bit floating point numbers. Maybe.
>>
>> Well, with an arbitrary-precision library, I'll bet it could. :-)
>
> Smartass :)
Ah, you've summed me up in a nutshell. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4798d43b@news.povray.org>, sau### [at] netscapenet says...
> > if you tried to add shortcuts, never
> > mind that there aren't a lot of free rendering systems that are as good
,
> > and also use those short cuts. Most of the other half would still be
> > busy sharpening the edges of their triangle primitives, just in case
> > your suggestion did break the physical based systems already in there.
> > lol But, I think you see what I am getting at. Even if some of us would
> > find it useful to take short cuts, its *not* what the program is
> > supposed to be designed for, and what it *is* intended for isn't
> > functionally possible in current GPUs.
>
> I see. As I wrote, I would like this only as rough/test/WIP/preview,
> specially if the rough/test/WIP/preview could be rendered fast or in
> real-time. The final output is and should always be SLOW for HIGHEST
> quality purposes, which I enjoy very much. Actually I enjoy rendering
> POV-Ray images slowly, since version 1.0 (which I still have), since
> real-time Virtual Reality renderers are impossible for most if not all
> of us, getting only one frame of VR slow is just fine for me :)
>
Well, some people have built prototype versions that "do" use OpenGL to
provide previews. And, they work OK, so long as you are not using stuff
that they currently have no way to tessellate or extrapolate into the
architecture needed to use the GPU. So, yeah, some people do think that
doing so is sort of useful. The real question is going to be if it ever
gets to the point of supporting enough features to be "useful enough".
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Gelato uses undocumented proprietary GPU commands on the cards.
>
> I think you are mistaken here. nVidia has lots of info about how to
> program their GPUs, just go to the developer section, they have lots of
> MegaBytes of info and a free developer enviroment, downloadable.
NVidia wants developers to use Gelato, or more generally CUDA.
NVidia wants to control who does or doesn't know about the
primitive commands used to access the GPU.
It's right in the CUDA license...
"Object Code: Developer agrees not to disassemble, decompile
or reverse engineer the Object Code versions of any of the Materials.
Developer acknowledges that certain of the Materials provided in
Object Code version may contain third party components that
may be subject to restrictions, and expressly agrees not to attempt to
modify or distribute such Materials without first receiving consent
from NVIDIA."
Although I can't locate it at the moment, there was a statement
in some of the online docs about Gelato using special (non-Cuda)
commands to speed up some of their rendering.
So it might be possible to build some acceleration into POV via
the CUDA SDK, but you would have to request permission from
NVidia in order to distribute it, and Gelato will always be faster.
Historically, 3D modelers that can output to POV have used
Open-GL as a preview, in order to do that they provide a
tesselation of POV primitives to Open-GL. There is no reason
why a modeler couldn't use DirectX as a preview as well, though
that makes it Windows specific.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The GPU can be only used for certain task. It's not a generic processor
> like the CPU is. There are other tasks which are very inefficient and
> difficult to do with the GPU. And of course there are tasks which are
> simply impossible to perform with the GPU.
>
> Not all tasks related to computer graphics can be performed with the
> GPU. The GPU is specialized in a certain type of calculations.
I see.
> One feature of GPUs is that they are good at making the same calculations
> in parallel. For example, if you are applying a filter to an image the
> GPU is superb for this. That's because the exact same filter can be
> applied to every single pixel of the image. It's the one and same task
> performed over a set of data.
>
> Raytracing isn't such a task, though. Rays may or not get reflected and
> refracted, split into two, they may or may not be used for shadow testing,
> they may or may not be used to sample media, a texture may or may not be
> evaluated at an intersection point... It's hard to do these things with
> a GPU.
I see your point.
> Another killer is that GPUs don't support recursion, while raytracing
> obviously requires it.
can it be emulated by programming it? if so would the penalty would be
too big?
>> Why are you so negative about it?
>
> I'm not negative. I'm realist.
Yes, is true, you're pretty realistic, I may have assumed too much.
> I don't like to raise false hope.
Which is fair
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, yeah, some people do think that
> doing so is sort of useful. The real question is going to be if it ever
> gets to the point of supporting enough features to be "useful enough".
So you think it's not useful? Have you every used one or have any stats
on them? or you know someone who did/does? I want statistics to know how
useful they really are. For what I read not in the acceptable range.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> there was a statement
> in some of the online docs about Gelato using special (non-Cuda)
> commands to speed up some of their rendering.
>
> So it might be possible to build some acceleration into POV via
> the CUDA SDK, but you would have to request permission from
> NVidia in order to distribute it, and Gelato will always be faster.
I see, well POV-Ray is fast enough for me and about this permission I
think the POV-Team could get it for free since they're developing a high
quality and complex freeware that requires lots of effort and time whoch
merits for some companies to donate some software to POV-Ray. I don't
think nVidia or any other company have the audacity to charge a freeware
developer team IMO.
> Historically, 3D modelers that can output to POV have used
> Open-GL as a preview, in order to do that they provide a
> tesselation of POV primitives to Open-GL. There is no reason
> why a modeler couldn't use DirectX as a preview as well, though
> that makes it Windows specific.
True, AND Open-GL is more fluent when you rotate around an objet or
objets are in motion than Direct X. I have experiencied this on games.
When you move around in a Direct X game I see a little blur and I don't
see this on Open-GL games. Considering the source of both technologies I
don't find this strange.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <479c1614@news.povray.org>, sau### [at] netscapenet says...
> So, yeah, some people do think that
> > doing so is sort of useful. The real question is going to be if it ever
> > gets to the point of supporting enough features to be "useful enough".
>
> So you think it's not useful? Have you every used one or have any stats
> on them? or you know someone who did/does? I want statistics to know how
> useful they really are. For what I read not in the acceptable range.
>
I said, "useful enough", not "not useful", just to clarify that. But
seriously, its got the same problem that trying to use things like
isosurfaces, or meshes, and the like in Moray has. If you can't "see"
how something that you add interacts in the preview, what is the point
of *having* a preview?
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I said, "useful enough", not "not useful", just to clarify that. But
> seriously, its got the same problem that trying to use things like
> isosurfaces, or meshes, and the like in Moray has. If you can't "see"
> how something that you add interacts in the preview, what is the point
> of *having* a preview?
There's absolutely no reason why meshes shouldn't be visible in a real-time
previewer. And iso-surfaces are easily meshed using a number of different
algorithms. OK, it's more work than meshing a cube or cylinder, but it's
certainly not impossible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <479edf92@news.povray.org>, sco### [at] laptopcom says...
> > I said, "useful enough", not "not useful", just to clarify that. But
> > seriously, its got the same problem that trying to use things like
> > isosurfaces, or meshes, and the like in Moray has. If you can't "see"
> > how something that you add interacts in the preview, what is the point
> > of *having* a preview?
>
> There's absolutely no reason why meshes shouldn't be visible in a real-ti
me
> previewer. And iso-surfaces are easily meshed using a number of differen
t
> algorithms. OK, it's more work than meshing a cube or cylinder, but it's
> certainly not impossible.
>
Yes. Just not entirely feasible, in some cases. lol Seriously though,
the biggest issue isn't necessary those, but tessellation of other
things, which are normally calculated more directly. You have to do a
lot of work to "got" the preview, before you can use it, work that
wouldn't be needed so much in a system that generated triangle based
objects to start with. And, it doesn't change the fact that its not as
useful without a complete set as *with* one. Aside from the gripe I have
with Moray using a different coordinate system than the one I am *used
to* using when hand coding, such that mixing stuff doesn't work so well,
its also "missing" a lot of things that are either just left out, or
kind of complicated to actually support. And no, hand entering code some
place, so that it renders "after" you send it to POVRay is *not*
supporting the feature. Support, in this case, is when you can *see* it
in the modelers view first, so you don't have to do a 3 day render to
see if your hand entered code worked. lol OpenGL preview, same problem.
Its either all, nearly all (which is still fairly acceptable, depending
on what got left out and why), or nothing.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
