 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tyler Eaves wrote:
>
POV-Ray is a renderer. That means that if it can render something
you can describe in the SDL, POV-Ray does all it needs to do. The
only reason to add a new feature is:
a) What you want cannot be described in the SDL.
b) What you want can be far more efficiently rendered as a new
primitive.
The things you ask for don't fall into either category.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40577bfc@news.povray.org>, Warp <war### [at] tag povrayorg>
wrote:
> However, if you make code which calculates something without creating
> objects, then quite obviously memory allocation is not an issue there.
Unless the memory allocation is actually lots of small chunks of memory
that are quickly freed again...small temporary structures for values
during expression parsing, for example. In a loop, it may create a new
variable structure for every update of the loop counter, causing extra
memory allocations.
Anyway, the slowness certainly is due to more than memory allocation,
and switching to a VM certainly would speed things up. Memory allocation
does account for a big chunk of the parse time, though...scenes can
consist of many megabytes of small structures, and allocating all of
these takes time. Maybe do something to handle structures that will last
the entire render differently from those that are short term.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it andrel who wrote:
>Hi mike,
>
>Lars Petter in the thread: 'questions on parametric objects
>and 3d splines'
>is looking for your SweepSpline macro's. The zip file you
>posted in november seems to be broken.
The November version is also in the download zip on that page as
sweepsplineV2.inc, the current version, in the same download file is
just called sweepspline.inc
>Mike Williams wrote:
>
>> Or you could use my sweepspline.inc to approximate this with a mesh2.
>> It's at the bottom of <http://www.econym.demon.co.uk/isotut/more.htm>
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <MPG.1ac147e51c2d571d9899e7@news.povray.org> , Patrick Elliott
<sha### [at] hotmailcom> wrote:
> One thing that would be very helpful in byte code is 'parse once, run
> multiple times'.
This is impossible with the current POV-Ray SDL because it offers
self-modifying and self-generating capability.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 16 Mar 2004 00:17:45 -0500, Tyler Eaves <tyl### [at] NOSPAMml1net>
wrote:
>4. Ability to dump a object to a binary format
> This goes with 2. and 3. above. The desire here is to cut to the
> chase and provide an efficient way to save and load objects. Again,
> the idea here is to greatly reduce the speed hit for "recursive
> objects". I don't think things like platform or version independence
> are a big deal here, so maybe this wouldn't be too hard to code?
This comes up quite often and the problems with it are well known. But
what do you think of XML? The scene structure is internally very well
defined and there are no ambiguities, so XML with a proper doctype (or
whatever is applicable for XML that defines the various tags and their
parameters etc.) might actually have its use, even maybe for limited
exporting from POV to other formats.
I wonder what the more tech-savvy think about this.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
> This is impossible with the current POV-Ray SDL because it offers
> self-modifying and self-generating capability.
True, this makes it a bit more difficult.
Another problem is that pov-file may #include itself, which is another
extra twist to take into account when dealing with bytecode.
Speaking of #includes, one thing which may speed up a lot when implementing
bytecode compiling/interpreting would be to have support for pre-compiled
include files. That is, include files may be pre-compiled by the user and
then each time that include file is #included, the already-parsed-and-compiled
version is quickly loaded instead of the original one. This can save a great
deal of parsing and compiling.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <evi### [at] hotmailcom> wrote:
> POV-Ray is a renderer.
POV-Ray is more than a renderer.
Besides, what's wrong with wanting POV-Ray to be faster? I thought we
all wanted that.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] vipbg> wrote:
> >4. Ability to dump a object to a binary format
> This comes up quite often and the problems with it are well known. But
> what do you think of XML?
I think that the idea of dumping an object to binary format is to
save space and that it's very quick to load. XML does not.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <mo6g501d7c7cm15eim39k64mhug29jjf3v@4ax.com>,
Peter Popov <pet### [at] vipbg> wrote:
> This comes up quite often and the problems with it are well known. But
> what do you think of XML? The scene structure is internally very well
> defined and there are no ambiguities, so XML with a proper doctype (or
> whatever is applicable for XML that defines the various tags and their
> parameters etc.) might actually have its use, even maybe for limited
> exporting from POV to other formats.
Bloated, the resulting files would be huge, and it adds another layer of
parsing. A binary format would be much faster to load, and far more
compact. I don't like XML...I do like the concept behind it, but I think
the execution sucks.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Mike,
Mike Williams wrote:
> Wasn't it andrel who wrote:
>
>>Hi mike,
>>
>>Lars Petter in the thread: 'questions on parametric objects
>>and 3d splines'
>>is looking for your SweepSpline macro's. The zip file you
>>posted in november seems to be broken.
>
>
> The November version is also in the download zip on that page as
> sweepsplineV2.inc, the current version, in the same download file is
> just called sweepspline.inc
Whoops, I followed the wrong link (to #plathe and then to spline35.zip)
and found only *.pov files. Now I have them I think I will play
around with them a bit. BTW did you notice that in sweepspline.inc
you copied the line with the 'secion' typo repeatedly?
Thanx
>
>>Mike Williams wrote:
>>
>>
>>>Or you could use my sweepspline.inc to approximate this with a mesh2.
>>>It's at the bottom of <http://www.econym.demon.co.uk/isotut/more.htm>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
