On 1/19/2010 2:23 PM, Jim Henderson wrote:
> 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

You know.. There is one bit of irony in this whole mess. If you look at 
something that "attempts" to do building in a virtual environment you 
get the god awful mess of Second Life/Opensim, and there idea of 
"prims". While the purpose of POVRay hasn't been to create a game engine 
at all, its tiresome to see such total junk produced to do what POVRay 
does well, which is let you build stuff, without making it in a $500 
application that handles nothing but meshes.

I would love nothing else than to see POVRay like design features, and 
real primitives, integrated into a GPU supported system, that worked 
better than the stuff on the market. Both have handicaps. POVRay due to, 
until now, there being no feasible way to use a GPU to help it, and 
everything else by the fact that the *best* real time generation of a 
scene, based on anything close to a data set that defines what you are 
looking at, its a bloody disaster, because its trying to use stuff that 
works mathematically with predefined meshes, and various cheats, to 
*fake* CSG effects, which it can't actually manage at all.

You could use half as many "prims", end up with better results, and use 
the half you end up left over to add detail, if SL/Opensim used real 
primitives, even *with* the idiocy of having to tessellate them into a 
mesh first. Its absurd, and annoying, and I dream of the day someone 
manages to fix the problem. But, based on my understanding, that 
**isn't** going to happen any time soon, especially not unless POVRay 
picked up some heavy hitters, who knew the other code well, and actually 
thought it would be a good idea to produce something that used the best 
of both. The team doesn't have such a person, and even if it did, it 
would still need to get 3.7 working, without such added functionality, 
and that, for now, is the reason its not going to happen now, or 
necessarily even "soon".

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     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