 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"nemesis" <nam### [at] gmail com> wrote:
> I'll be downloading the source-code tonight to see things for myself and
> perhaps implement a demo for my #includeas proposal...
Nice :)
I think some friendly competition would be beneficial to the whole POV-Ray
project. I have a feeling that we - the community - are on our way to
discovering some amazing new implementations in the SDL, whatever it ends
up looking like. If my "retroactive aliasing" model ends up being nothing
more than a pipe dream, then so be it.
I'm looking forward to seeing what you come up with.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I'm looking forward to seeing what you come up with.
i'll have to actually get down to C level because it was with much sadness
that i witnessed for the first time how limited file I/O is in the SDL:
#read don't work as expected, it's actually more akin to C's scanf. This
is sad because i was trying to write a includeas macro which would scans
the included files line-by-line to search for #declares and rewrite them
with prefixes... no way to do it... so, C we go!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW to nemesis and anyone else whose been following the the topic of
'aliasing':
I recently made reference to "cork" and "tungsten" (Includes - Standards
#53). If you didn't already know I was referring to, here it is:
Legend has it that Thomas Edison already knew that the electric light bulb
was possible in principle before he actually made one that worked. All he
needed was to find the right material for the element. Instead of ruling
out any possibility, he decided to try every material he could think of -
even the ones he knew wouldn't work - including cork. Eventually he
settled on tungsten - it worked the best.
Alchemically speaking: Of all the metals in the periodic chart, tungsten
has the highest melting-point. I feel that well-made software should be
like tungsten. It should glow white-hot without burning out when you put a
high current through it. I'll leave the gold to the user in posession of
the software that's made of tungsten.
-Randall
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> Has it been decided that SDL will get a complete overhaul, then? And
> what about backwards compatibility - is POV-Ray finally giving up on it?
As far as I know, nothing specific has been discussed yet. However, it has
been long been a simple fact that the current SDL is a bunch of kludges over
older kludges and it just doesn't scale. Adding more and more new features
to the current SDL just makes it worse, not better.
A "new SDL" doesn't necessarily mean a new scripting language which will
look completely different from the current SDL, although I'm sure that
whatever will be developed, there will be some differences, but only for
the better.
The user-defined functions in POV-Ray (which form their own syntax space,
separate from the SDL, and which are about 100 times more efficient than
#macros because they are byte-compiled) is a step towards the ultimate goal.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Alchemically speaking: Of all the metals in the periodic chart, tungsten
> has the highest melting-point. I feel that well-made software should be
> like tungsten. It should glow white-hot without burning out when you put a
> high current through it. I'll leave the gold to the user in posession of
> the software that's made of tungsten.
Povray is culture too. :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> This is because, if the #macro is indeed in an included file, POV-Ray will
> open that file, seek to the macro, parse it and close the file, and this each
> time the macro is called.
I knew this, but I never realized one of the implications before: If
you're working on writing macro code, and you start a render, you may
break the render by editing the file the macro is in before the render
is done, yes?
(Of course, on decent operating systems, and even Windows, reading the
same file a bunch of times in a row isn't all that much overhead,
compared to reading it the first time.)
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> I knew this, but I never realized one of the implications before: If
> you're working on writing macro code, and you start a render, you may
> break the render by editing the file the macro is in before the render
> is done, yes?
Only during parsing.
> (Of course, on decent operating systems, and even Windows, reading the
> same file a bunch of times in a row isn't all that much overhead,
> compared to reading it the first time.)
Even in decent OSes it is a lot of overhead compared to eg. having
the macro in memory. Or even in the same file.
You can test this in practice: Make a loop which calls a macro which
is located in another file and measure how long it takes. Then move the
macro to the current file (where the loop is) and measure again. You will
probably get a significant increase in speed.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Only during parsing.
Oh yes. That makes sense. Most of my scenes parse pretty quickly, even
the big ones.
--
Darren New / San Diego, CA, USA (PST)
Scruffitarianism - Where T-shirt, jeans,
and a three-day beard are "Sunday Best."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> This is because, if the #macro is indeed in an included file, POV-Ray will
> open that file, seek to the macro, parse it and close the file, and this each
> time the macro is called. Thus the overhead is about as bad as an explicit
> #include call.
Would it be possible for POV-Ray to hold all already-parsed files in a
memory buffer, so it wouldn't have to open them multiple times? I
realize this might take a bit of work to deal with potential rewrites of
the macro via the file I/O options, but it would be shedloads faster
than the current method, I think.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers nous apporta ses lumieres en ce 07/12/2006 06:45:
> Warp wrote:
>> (This, among other things, is a direct consequence of the history of
>> the SDL, which is just one kludge over another over the years, and a big
>> reason why pov4 is intended to be written from the scratch and with a
>> much better SDL.)
> Has it been decided that SDL will get a complete overhaul, then? And
> what about backwards compatibility - is POV-Ray finally giving up on it?
> (Not that it would necessarily be a bad thing, I just don't remember
> hearing that).
> ...Chambers
There already are some backward compatibility breakages. Try rendering a scene
that use "athmosphere" or "hallo". NO version setting can make them work!
Any scene using radiosity or spline may render differently in future versions,
maybe needing editing as some keywords can be dropped or replaced.
--
Alain
-------------------------------------------------
After any salary raise, you will have less money at the end of the month than
you did before.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
