 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmail com> wrote:
> They seem tedious more than difficult....I hate tedium.
It's no different from looping to place compound objects; you write macros to do
the work for you. To be sure, it requires a bit of concentration to get to the
first stage, but once you've got something that renders it's just tweaking. It
can be helpful to draw diagrams to aid with the visualisation.
Use plain mesh (i.e., just triangle statements) - it's much easier than mesh2.
(To be honest, mesh2 is mainly a handy conversion format for speeding up
parsing, you only need to use it if you're generating 10000s of triangles.
They're both the same thing once parsing is complete).
> I'll take a look at that there, and given that those are blades of grass,
> its probably not too far off from what I want to do with moss leaves anyway,
> I'd just need to grab one blade.
I've been trying to write a decent plant include file for a while now. I've got
a leaf macro that builds different shaped leaves procedurally, and I'm slowly
adding types of plants to use it. It's a long-term work in progress, but I've
got grass and dandelions so far. No ivy leaves yet, though. I can post the leaf
macro later if you're interested...?
> Suprisingly, its not the vine routes that takes the time, its tracing the
> moss onto the individual vine components.
Write random locations on the vine routes to a data file as you go, then read
them back in when you place the moss? Or the same thing, but using an array?
Every time you make a vine section, #if rand(seed) < probability then store the
current endpoint, or something.
There's more than one way to skin a cat, I'm sure you've got it in hand... :)
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote in message
news:web.49b783c2d4fd5b286dd25f0b0@news.povray.org...
> It's no different from looping to place compound objects; you write macros
> to do
> the work for you. To be sure, it requires a bit of concentration to get to
> the
> first stage, but once you've got something that renders it's just
> tweaking. It
> can be helpful to draw diagrams to aid with the visualisation.
>
> Use plain mesh (i.e., just triangle statements) - it's much easier than
> mesh2.
> (To be honest, mesh2 is mainly a handy conversion format for speeding up
> parsing, you only need to use it if you're generating 10000s of triangles.
> They're both the same thing once parsing is complete).
I'll definately give that a try once I get most of these macros to public
beta. :-)
>
> I've been trying to write a decent plant include file for a while now.
> I've got
> a leaf macro that builds different shaped leaves procedurally, and I'm
> slowly
> adding types of plants to use it. It's a long-term work in progress, but
> I've
> got grass and dandelions so far. No ivy leaves yet, though. I can post the
> leaf
> macro later if you're interested...?
>
Of course, and if the macro parameters are expected to be stable, I could
make my macro implement yours, if that is cool.
>
> Write random locations on the vine routes to a data file as you go, then
> read
> them back in when you place the moss? Or the same thing, but using an
> array?
> Every time you make a vine section, #if rand(seed) < probability then
> store the
> current endpoint, or something.
>
> There's more than one way to skin a cat, I'm sure you've got it in hand...
> :)
>
I've been using arrays, and in fact most of the macros I've been writing
recently implement component macros that I wrote for the snow macro.
It turns out that to reduce the parse time for this particular use, all I
had to was change a single line. I now have to perform only 5000 tests to
get the ~same number of placed objects as previously required 500k. This has
resulted in a much lower threshold for catastrophically crashing povray due
to lack of available memory.
I doubt that I can get around the out of memory error by writing to a file.
Unless povray can read/write a part of a file without loading the whole
thing, or unless somehow a file would take less memory for the same amount
of data than would an array, I don't see any way around this problem in its
entirety.
Granted, using a mesh would free up a LOT of spaces used by the moss array,
as each moss frond takes 260 at current settings. Multiply that by the
amount of tests per vine sub-object...
I think that would go a long way to increasing the ceiling that I'm hitting.
I think I might need to determine the average amount of ram used per
"mossed" vine object, so that I can allow a user to input their total
available ram (for 32 bit systems this will always be 2gb), which would not
let the macro run so far as to give people those blood boiling OOM errors.
Here is the result of the one line change, in image and stats. Compare that
to the previous one posted...big improvement.
ian
Scene Statistics
Finite objects: 1013230
Infinite objects: 0
Light sources: 1
Total: 1013231
Possible Rendering Error: Maximum trace level reached! If your scene
contains black spots read more about the max_trace_level setting in the
documentation!
Render Statistics
Image Resolution 1280 x 1024
Pixels: 1312000 Samples: 1502912 Smpls/Pxl: 1.15
Rays: 2047633 Saved: 0 Max Level: 5/5
Ray->Shape Intersection Tests Succeeded Percentage
Cone/Cylinder 1189022659 11408002 0.96
CSG Intersection 45321691 2913618 6.43
CSG Union 1087005314 669132 0.06
Sphere 2168288631 860782 0.04
Bounding Box 396224017 110147439 27.80
Light Buffer 672753438 349217503 51.91
Vista Buffer 144135167 115783532 80.33
Calls to Noise: 0 Calls to DNoise: 1345012
Shadow Ray Tests: 2359688 Succeeded: 952498
Transmitted Rays: 544721
I-Stack overflows: 28578
Smallest Alloc: 18 bytes
Largest Alloc: 8105856 bytes
Peak memory used: 1414575125 bytes
Total Scene Processing Times
Parse Time: 0 hours 12 minutes 34 seconds (754 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Cloth Time: 0 hours 0 minutes 0 seconds (0 seconds)
Mechsim Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 1 minutes 7 seconds (67 seconds)
Postpr. Time: 0 hours 0 minutes 0 seconds (0 seconds)
Total Time: 0 hours 13 minutes 41 seconds (821 seconds)
CPU time used: kernel 15.09 seconds, user 794.44 seconds, total 809.53
seconds
Render averaged 1619.11 PPS over 1310720 pixels
POV-Ray finished
Post a reply to this message
Attachments:
Download 'VineTest1_2_1.jpg' (13 KB)
Preview of image 'VineTest1_2_1.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Of course, and if the macro parameters are expected to be stable, I could
> make my macro implement yours, if that is cool.
Could do, but I may change it considerably yet; that's why I've not posted it
anywhere. You could always just plunder my code to make your own leaf, which is
what I was getting at ;-)
> I doubt that I can get around the out of memory error by writing to a file.
> Unless povray can read/write a part of a file without loading the whole
> thing, or unless somehow a file would take less memory for the same amount
> of data than would an array, I don't see any way around this problem in its
> entirety.
Your memory usage is still heinous. There's no way you should need to use more
than a fraction of that for this sort of thing.
I don't understand where all your data is coming from. Surely all you need to
store in an array is a position and maybe a normal for each moss object? There
can't be more than 10,000 visible 'mosses' in that image.
> Granted, using a mesh would free up a LOT of spaces used by the moss array,
> as each moss frond takes 260 at current settings.
Why aren't you #declaring a moss frond, storing position data (i.e. vectors)
in the array, then instancing the #declared frond? Your image simply does not
have enough complexity to account for that memory usage.
Whenever I've done something like this in the past, I've racked up some severe
parsing times, but rarely more than a few 10s of MB of peak RAM.
> Peak memory used: 1414575125 bytes
*clunk*
*wires jaw back on*
:)
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> Your memory usage is still heinous. There's no way you should need to use more
> than a fraction of that for this sort of thing.
Sorry, please disregard my disbelief, I've got so accustomed to using meshes for
this that I forget just how much memory normal objects take up. On reflection,
it doesn't seem so silly.
So:
The reason you're running out of memory is that every instance you use takes up
the same memory as the original, so there's no advantage to instancing. Meshes,
however, are stored just once. All mesh instances are actually just transforms,
so they take up a minute amount of space. I guarantee that if you use meshes
for your fronds, even quite complex ones, you will save over 95% of the memory
you're currently using!
You can even go further and use them for the ivy creepers, although that's
probably not so serious.
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill Pragnell" <bil### [at] hotmailcom> wrote in message
news:web.49b7b7d6d4fd5b286dd25f0b0@news.povray.org...
> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
>> Your memory usage is still heinous. There's no way you should need to use
>> more
>> than a fraction of that for this sort of thing.
>
> Sorry, please disregard my disbelief, I've got so accustomed to using
> meshes for
> this that I forget just how much memory normal objects take up. On
> reflection,
> it doesn't seem so silly.
>
> So:
>
> The reason you're running out of memory is that every instance you use
> takes up
> the same memory as the original, so there's no advantage to instancing.
> Meshes,
> however, are stored just once. All mesh instances are actually just
> transforms,
> so they take up a minute amount of space. I guarantee that if you use
> meshes
> for your fronds, even quite complex ones, you will save over 95% of the
> memory
> you're currently using!
>
> You can even go further and use them for the ivy creepers, although that's
> probably not so serious.
>
> :)
>
>
Check this out (apologies for the horrific texture):
I exported this from Bryce and converted with poseray.
Scene Statistics
Finite objects: 145243
Infinite objects: 0
Light sources: 1
Total: 145244
Possible Rendering Error: Maximum trace level reached! If your scene
contains black spots read more about the max_trace_level setting in the
documentation!
Render Statistics
Image Resolution 1280 x 1024
Pixels: 1312000 Samples: 2094440 Smpls/Pxl: 1.60
Rays: 2176126 Saved: 0 Max Level: 5/5
Ray->Shape Intersection Tests Succeeded Percentage
Cone/Cylinder 1088334589 1326340 0.12
CSG Union 1087005314 669132 0.06
Mesh 67373038 2668035 3.96
Sphere 2167394361 366116 0.02
Bounding Box 869147567 316790036 36.45
Light Buffer 449711964 194011242 43.14
Vista Buffer 465015215 340904239 73.31
Calls to Noise: 0 Calls to DNoise: 1114198
Shadow Ray Tests: 1505186 Succeeded: 494705
Transmitted Rays: 81686
I-Stack overflows: 28578
Smallest Alloc: 18 bytes
Largest Alloc: 1161960 bytes
Peak memory used: 158859969 bytes
Total Scene Processing Times
Parse Time: 0 hours 11 minutes 53 seconds (713 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Cloth Time: 0 hours 0 minutes 0 seconds (0 seconds)
Mechsim Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 1 minutes 43 seconds (103 seconds)
Postpr. Time: 0 hours 0 minutes 0 seconds (0 seconds)
Total Time: 0 hours 13 minutes 36 seconds (816 seconds)
CPU time used: kernel 20.84 seconds, user 780.28 seconds, total 801.13
seconds
Render averaged 1636.10 PPS over 1310720 pixels
POV-Ray finished
Post a reply to this message
Attachments:
Download 'VineTest1_2_2.jpg' (33 KB)
Preview of image 'VineTest1_2_2.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>
> Check this out (apologies for the horrific texture):
> I exported this from Bryce and converted with poseray.
>
I dunno, I kind of like this texture--looks like tiny crystals forming (or
whatever the word is) out of a liquid solution.
KW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Well, to clairify, the only thing I exported from bryce was the plant, which
I then retextured in Poseray.
:)
ian
"Kenneth" <kdw### [at] earthlinknet> wrote in message
news:web.49b8176ad4fd5b28f50167bc0@news.povray.org...
> "[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>
>>
>> Check this out (apologies for the horrific texture):
>> I exported this from Bryce and converted with poseray.
>>
> I dunno, I kind of like this texture--looks like tiny crystals forming (or
> whatever the word is) out of a liquid solution.
>
> KW
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ok, a little better here. Well...at least a bit closer to what I'm shooting
for. It is clear that I will need to add another inside() test for whatever
object is being grown upon, as you can see here some of these clumps are
partially within the column.
I think I need to add the capability to not create hidden objects. There are
two ways which come to mind, the first of which being to detect all vectors
on the target object which are hidden and exclude them from the generation
of random vectors in that macro. This seems like it might be the most
efficient way method. The second of which would be to perform the test
within the object placement macro.
I'm not sure which would give the best results, so I guess I'll need to
implement both and see what happens.
I think the macro that clipka posted in response to my hidden glow problem
will do the trick nicely.
Any thoughts?
ian
Post a reply to this message
Attachments:
Download 'VineTest1_2_3.jpg' (16 KB)
Preview of image 'VineTest1_2_3.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here's my leaf macro as it stands:
http://www.infradead.org/~wmp/leaf.inc
It's more comprehensive than I remember - all the leaf types apart from stalks
and grassblades have uv vectors (u along the length of the leaf, v from the
centre to the edges), so uv_mapped textures will work with them. Also, the
macro only produces triangles - it has to be called from inside a mesh block -
this means you can have as many leaves as you want in a single mesh.
Enjoy!
Bill
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Finite objects: 1013230
> Peak memory used: 1414575125 bytes
I reckon your memory issues are not *per se* due to using a bucketload of CSG
instead of a few meshes.
I just did a quick test with 10k spheres, with a color-mapped pigment; the
following might give you some hints how to improve performance:
- With all spheres being generated on-the-fly as scene-level objects, I get a
peak mem of ~8 MB.
- If I #declare the material first, and use that in my spheres "as is" (no
translations, rotations or any modifications), peak mem reduces to ~6.5 MB.
- If I place the spheres in a union and attach the material only to the union,
peak mem reduces to ~3.6 MB.
- If I #declare the sphere first, and use translated copies, peak mem goes *UP*
again to ~6.4 MB!
- Worst thing I got so far was #declare the sphere first with a material, and
use translated copies, giving me ~12 MB!
Another thing I found was that first generating an array with object locations,
and then creating the objects in a separate pass, is more costly than creating
an array of objects right away.
Still, here's the best advice:
- If instead of generating 10000 spheres I #declare a mesh of 100 triangles,
then generate a union of 100 translated copies of it, I get a peak mem of lousy
~360 kB, which is just ~170 kB over my "baseline" peak mem. Even with 1000
copies, I still need just ~1.4 MB peak.
Given that you'll possibly need only one triangle per leaf to replace a pair of
cones (unless you want to do extreme close-ups - note that you can still
simulate curvature using a smooth triangle), this should be a good enough model
to give you a rough estimate of how much memory you can save.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
