 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis nous apporta ses lumieres en ce 07/12/2006 07:42:
> Warp <war### [at] tag povrayorg> 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.
> oh, man! This is freakish bad! It really read the include file each time
> the macro is called?! Is it an easy way to get local scoping for the macro
> by using the stabilished local file for the include files?... that hurts...
> I'll be downloading the source-code tonight to see things for myself and
> perhaps implement a demo for my #includeas proposal...
What you can do is #declare MyMacro = IncludedMacro
Then, if you need many instances of the macro, you work on the copy, saving you
from having to open and read the include file each time.
--
Alain
-------------------------------------------------
Are you a Klingon, or is that a turtle on your head?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Brucker nous apporta ses lumieres en ce 07/12/2006 10:21:
> nemesis wrote:
>> OTOH, is there real need for a single file with 50+ parameters? Must the
>> user actually set all of those any time they call the include?
>> If they are needed, then it's not much better than a 50+ parameter macro
>> call, except parameters are named.
> Most of them have sensible default values, so normally you don't need to
> change all of them for every run. But it depends on the scene which
> parameters you have to tweak, so using a fixed declare/parameter
> combination is not feasible. If those include files were for public use
> I'd create a more userfriendly interface by reducing the possible
> parameters. But these are rather experimental files for trying out
> different algorithms, so I prefer the freedom over the simplicity :)
> Regards,
> Florian
An example of an include that can need 50+ parameters: blob man. Most parameters
have default values, you only change those you need using many #declare.
--
Alain
-------------------------------------------------
'I never met a piece of chocolate I didn't like.'
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> 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.
>
Yes, but those features cause a warning in the output that backwards
compatibility will not necessarily be maintained.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 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.
Indeed, examples of things that will certainly change are all those little
bits and pieces where the language itself is inconsistent. I.e. in some
places we use [ ... ] for maps and in others we don't. And then there are
those objects where the syntax specifies the number of elements in advance,
which isn't (always) necessary at all, and in various cases just makes
hand-editing a scene hard. Then there are the bits and pieces where you
cannot actually use dot (aka ".something") syntax as expected. And so on,
and so on.
Plus of course, various directive issues, like the fun stuff you can do with
macros writing to files including macros (a kind of self-modifying code),
which makes parsing a mess, slow, and can even make it unreliable. And while
this may go, certainly there will be a way to parse from user-generated
strings instead (which is much easier to deal with). Oh, and even in 3.7 the
way (user generated) files are handled will, before the last beta, will
become more secure and predictable.
> 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.
Plus, at long last there is a good and reliable VM technology available as
true open sources, in form of llvm (see llvm.org). So count on seeing that
as new backend for functions to appear the the (distant) future. At long
last we can then even support the famous "plug ins", *if* (AND ONLY IF!!!)
we decide we want that.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> Indeed, examples of things that will certainly change are all those little
> bits and pieces where the language itself is inconsistent. I.e. in some
> places we use [ ... ] for maps and in others we don't. And then there are
> those objects where the syntax specifies the number of elements in advance,
> which isn't (always) necessary at all, and in various cases just makes
> hand-editing a scene hard. Then there are the bits and pieces where you
> cannot actually use dot (aka ".something") syntax as expected. And so on,
> and so on.
Splines? :-) I use them a LOT now knowing they may change. It'd be really
cool though if the same variable could simultaniously be treated as an
array of the defining vectors (4d format) & as a spline. I.e MySpline[5]
returns a 4D vector where t was the value along the spline & MySpline(0.5)
would do what it does now.
> Plus of course, various directive issues, like the fun stuff you can do with
> macros writing to files including macros (a kind of self-modifying code),
> which makes parsing a mess, slow, and can even make it unreliable. And while
> this may go, certainly there will be a way to parse from user-generated
:-( No more arbitrary text output? Does that mean quotation mark
encapsulated & comma-separated output only?
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Charles C <nomail@nomail> wrote:
> > Plus of course, various directive issues, like the fun stuff you can do with
> > macros writing to files including macros (a kind of self-modifying code),
> > which makes parsing a mess, slow, and can even make it unreliable. And while
> > this may go, certainly there will be a way to parse from user-generated
> :-( No more arbitrary text output? Does that mean quotation mark
> encapsulated & comma-separated output only?
No, it doesn't mean that.
One of the (very many) problems in the current SDL is precisely the
limitations on file handling (both writing and especially reading),
which is something I am sure will be made a lot more generic and versatile.
(One application I envision is an include file which imports/exports from/to
another format, eg 3DS.)
It just means that writing a file using SDL and then including it may
need to be limited.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> What you can do is #declare MyMacro = IncludedMacro
> Then, if you need many instances of the macro, you work on the copy, saving you
> from having to open and read the include file each time.
I think you have a fundamental misconception about how macros work.
You didn't even test if that #declare even works.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers <ben### [at] pacificwebguycom> wrote:
> 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.
Of course it would be possible, but that's a really low-priority issue
right now, and will probably become obsolete with pov4.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
