 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> that and since Povray 3.7 has not been released yet
It looks close now though, but I worry it will be an eternity before v4
is ever released, which will be a big shame.
GPUs seem so fast and capable now, a POV type program that takes full
advantage of that would be awesome. Imagine being able to edit your
SDL, have it parse instantly and look around the fully path-traced scene
in real time, adjusting your SDL until it looks just right.
Productivity would be orders of magnitude better than how POV works at
the moment. With standard hardware available today that is (just about)
possible, in the coming years (surely before POV4 is released) even for
large complex scenes it will become possible.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/04/2012 08:49 AM, scott wrote:
>> that and since Povray 3.7 has not been released yet
>
> It looks close now though
Really? I thought all development work had stopped years ago...
> GPUs seem so fast and capable now, a POV type program that takes full
> advantage of that would be awesome. Imagine being able to edit your SDL,
> have it parse instantly and look around the fully path-traced scene in
> real time, adjusting your SDL until it looks just right. Productivity
> would be orders of magnitude better than how POV works at the moment.
> With standard hardware available today that is (just about) possible, in
> the coming years (surely before POV4 is released) even for large complex
> scenes it will become possible.
What you're talking about amounts to a complete rewrite of the entire
program. Only the SDL parser would remain unchanged. Plus, I'm pretty
sure all the trippy real-time GPU renderers we've seen only render
polygons, not true curved surfaces - which, let's face it, is the entire
*point* of using POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Really? I thought all development work had stopped years ago...
Seems like a lot of features have been added/improved in the last year
(I was just reading the last few change logs).
>> GPUs seem so fast and capable now, a POV type program that takes full
>> advantage of that would be awesome. Imagine being able to edit your SDL,
>> have it parse instantly and look around the fully path-traced scene in
>> real time, adjusting your SDL until it looks just right. Productivity
>> would be orders of magnitude better than how POV works at the moment.
>> With standard hardware available today that is (just about) possible, in
>> the coming years (surely before POV4 is released) even for large complex
>> scenes it will become possible.
>
> What you're talking about amounts to a complete rewrite of the entire
> program. Only the SDL parser would remain unchanged.
No, the parser needs rewriting too, it's way too slow.
> Plus, I'm pretty
> sure all the trippy real-time GPU renderers we've seen only render
> polygons, not true curved surfaces - which, let's face it, is the entire
> *point* of using POV-Ray.
Exactly, that's why we need POV4 asap - imagine the greatness!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What you're talking about amounts to a complete rewrite of the entire
>> program. Only the SDL parser would remain unchanged.
>
> No, the parser needs rewriting too, it's way too slow.
I'm not sure about "slow"; I think the way that macros are fundamentally
based on token substitution rather than value manipulation places a hard
limit on how fast the parser can be.
>> Plus, I'm pretty
>> sure all the trippy real-time GPU renderers we've seen only render
>> polygons, not true curved surfaces - which, let's face it, is the entire
>> *point* of using POV-Ray.
>
> Exactly, that's why we need POV4 asap - imagine the greatness!
I'm not sure if it's still the case, but it used to be that GPUs could
render stuff so fast because triangle rendering is hard-wired into their
design. Hence, if you were to make it render something that isn't
triangles, it would be drastically slower.
Perhaps still faster than a CPU though. That would still be nice...
(Then again, I haven't tried the beta yet. I hear it uses multiple CPU
cores now...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 03:55 PM, scott wrote:
> On 10/04/2012 15:36, Invisible wrote:
>> Well, /something/ has changed... It seems to be getting markedly quiet
>> in here lately.
>
> Let's see what I can do about that then :-)
Told you it was quiet in here. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/04/2012 9:01 PM, Orchid Win7 v1 wrote:
> On 10/04/2012 03:55 PM, scott wrote:
>> On 10/04/2012 15:36, Invisible wrote:
>>> Well, /something/ has changed... It seems to be getting markedly quiet
>>> in here lately.
>>
>> Let's see what I can do about that then :-)
>
> Told you it was quiet in here. :-P
>
You can't be reading that C++ thread.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Told you it was quiet in here. :-P
>
> You can't be reading that C++ thread.
No. C++ doesn't natively support threads.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/04/2012 9:23 PM, Orchid Win7 v1 wrote:
>>> Told you it was quiet in here. :-P
>>
>> You can't be reading that C++ thread.
>
> No. C++ doesn't natively support threads.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/19/2012 13:23, Orchid Win7 v1 wrote:
>>> Told you it was quiet in here. :-P
>>
>> You can't be reading that C++ thread.
>
> No. C++ doesn't natively support threads.
Zing!
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Zing!
Sometimes I impress myself. ;-) But not often...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
