 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v2 <voi### [at] dev null> wrote:
> Looks impressive so far. (Nice lighting too BTW.)
I used some area spotlights (to keep the render time lower.)
Glad you like it!
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Really cool! Is this something you could do a time-lapse growth on? (i.e
different numbers of loops) If so I'd really like to see an animation of
this.
Charles
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> Kenneth wrote:
> Excellent work, and a subject close to my own heart, so I can doubly
> appreciate your efforts.
>
> Some test renders from one of my many wip's
I keep looking at your vines with envious eyes. ;-) Just the right
combination of "angularness" and "curviness." I also see that your vines
sort of move slightly away from the tree surface here and there. Very nice.
My own cylinders do that, but not in any planned way (some do travel
across open space, but some also drill *through* the tree to get to their
next points.) Your images give me inspiration to try and fix that.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Charles C" <nomail@nomail> wrote:
> Really cool! Is this something you could do a time-lapse growth on? (i.e
> different numbers of loops) If so I'd really like to see an animation of
> this.
> Charles
My code, as-is, would produce very "jerky" animation, unfortunately. As
more leaves "popped" into view, each new one (AND all the previous ones)
would be rotated and angled in a *new* random way, for each frame of
animation. It wouldn't look at all like time-lapse photography; more like
very bad stop-motion animation. Though it might be a fun experiment to
try, just to see the comical effect!
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth wrote:
> Jim Charter <jrc### [at] msncom> wrote:
>
>>Kenneth wrote:
>>Excellent work, and a subject close to my own heart, so I can doubly
>>appreciate your efforts.
>>
>>Some test renders from one of my many wip's
>
>
> I keep looking at your vines with envious eyes. ;-) Just the right
> combination of "angularness" and "curviness." I also see that your vines
> sort of move slightly away from the tree surface here and there. Very nice.
> My own cylinders do that, but not in any planned way (some do travel
> across open space, but some also drill *through* the tree to get to their
> next points.) Your images give me inspiration to try and fix that.
>
> Ken
>
>
>
Thanks. Yes that was some mind bending code to write for my feeble
little mass of grey matter. After seeing your efforts I went back to
review what I done only to find that the sdl is all but incomprehensible.
Anyway, like you did, I presume, my basic idea was to generate some
random path for any vine to follow using trace points on the tree
surface. The next trick, as you did too I am sure, was to utilize the
trace function not only to locate contact points on the surface of the
tree, but then to accumulate underlying vines into the trace target so
that subsequent traces would find them too. And I of course, found like
you did, that the result looked like sprayed on silly string, when the
vines clung too closely to the other vines. So I implemented, I
believe, a technique where I did traces over a certain interval and used
only the "highest" points as the basis for a spline describing the
overriding vine. I could tune the interval and number of samples which
gave the ability to have it follow the surface to a controllable degree
(somewhat) Put this together with the other elements in the macro, and
the sdl becomes nearly unreadable. For some insane reason I have all
this scaling in there that is based on multiples of a base number which,
I think, was the height of the tree trunk.
Anyway, the "vined" tree in that image was intended to lead to more
ambitious things. Based on my somewhat hasty entry in the POVCOMP I
want to do more images in a similar vein but with much more elaborate
backdrops of jungle and vines etc. So I am following your efforts with
great interest. Perhaps I can find time this week to try and unravel my
routine and make it more readable in case you may find something usable
there, or something that leads to something usable.
While I usually use mesh to make stems and similar things along splines
I see to my surprise that I actually used blobs in that code.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter wrote:
> Kenneth wrote:
>
>> Jim Charter <jrc### [at] msncom> wrote:
> While I usually use mesh to make stems and similar things along splines
> I see to my surprise that I actually used blobs in that code.
Oh, now I remember why. It was because Warp posted an observation that
blob code allows you to "instance" a collection of components in that
and repeat them at little added memory cost, same way that mesh does.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter <jrc### [at] msncom> wrote:
> >
> Thanks. Yes that was some mind bending code to write for my feeble
> little mass of grey matter. After seeing your efforts I went back to
> review what I done only to find that the sdl is all but incomprehensible.
Yeah, I feel your pain. My own scene file has more //comments// that actual
code! It was the only way I could keep track of all the nested #ifs and
such. It's probably the *longest* code that I've yet attempted, and could
probably benefit from some house-cleaning.
>
> The next trick, as you did too I am sure, was to utilize the
> trace function not only to locate contact points on the surface of the
> tree, but then to accumulate underlying vines into the trace target so
> that subsequent traces would find them too.
Sad to say, I didn't do that. But should have. I was actually amazed that
my image 'looked like' the vines overlayed each other. A happy (though
unexpected) result of a tiny piece of arcane code, meant for something
else.
> ...So I implemented, I
> believe, a technique where I did traces over a certain interval and used
> only the "highest" points as the basis for a spline describing the
> overriding vine. I could tune the interval and number of samples which
> gave the ability to have it follow the surface to a controllable degree
> (somewhat)
Fascinating. I'll gonna try incorporating that into my own vine-making.
>
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] earthlinknet> wrote:
> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
> > Just out of interest, what sort of parse time vs render time are you looking
> > at?
>
> I should have made a note of that, but didn't. Total render time (using
> cylinders for vines) was between 3 and 4 hours on my 400MHZ Pentium II,
> using AA 0.2. Parse time was a small fraction of that--perhaps 5-to-10
> minutes at most.
I have more accurate results now: Parse time is only about 2 minutes, using
(sixty) vines of either type. But the scene with sphere_sweeps for vines
takes an astoundingly long time to render--after 19 hours of a *partial*
render, I did a quick calculation, and realized it would consume about 148
hours total!! But I also discovered that the reason wasn't just the
sphere_sweeps...it was due to two "area" spotlights in the scene. Changing
those to regular spotlights reduced the sphere_sweep render time
drastically, to a mere five hours. Area lights of any kind do slow down a
render, of course, but I don't really understand this area
light/sphere_sweep interaction, why it's so MUCH slower. (Thinking it might
be a bounding-box problem, I tried manually bounding each vine; but that
didn't improve the render time at all.)
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth nous apporta ses lumieres en ce 06/02/2006 06:01:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
>>"Bill Pragnell" <bil### [at] hotmailcom> wrote:
>
>
>>
>>I should have made a note of that, but didn't. Total render time (using
>>cylinders for vines) was between 3 and 4 hours on my 400MHZ Pentium II,
>>using AA 0.2. Parse time was a small fraction of that--perhaps 5-to-10
>>minutes at most.
>
>
> I have more accurate results now: Parse time is only about 2 minutes, using
> (sixty) vines of either type. But the scene with sphere_sweeps for vines
> takes an astoundingly long time to render--after 19 hours of a *partial*
> render, I did a quick calculation, and realized it would consume about 148
> hours total!! But I also discovered that the reason wasn't just the
> sphere_sweeps...it was due to two "area" spotlights in the scene. Changing
> those to regular spotlights reduced the sphere_sweep render time
> drastically, to a mere five hours. Area lights of any kind do slow down a
> render, of course, but I don't really understand this area
> light/sphere_sweep interaction, why it's so MUCH slower. (Thinking it might
> be a bounding-box problem, I tried manually bounding each vine; but that
> didn't improve the render time at all.)
>
> Ken
>
>
You may try choping the sphere_sweep into smaller pieces. A sphere_sweep have a prety
large bounding
box that is mostly empty. As you have 60 sweeps in the same area, all bounding boxes
pile up leading
to a very ineficient situation. By subdividing it, you get smaller, tighter, bounding
boxes that
overlap less with each other.
When you test to see if you are in the shadow, you first check for the bounding box,
you hit 60 of
those for EACH test. Then, for each bounding box you encounter, you need to evaluate
the whole sweep
to see if it does cast a shadow on that particular point. In the case of area_light,
you have to
multiply that by the number of samples that you need to take. "adaptive" is a great
time saver,
start at adaptive 0 and increase by 1 as needed.
--
Alain
-------------------------------------------------
For THIS I bought a computer?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> You may try choping the sphere_sweep into smaller pieces. A sphere_sweep have a
prety large bounding
> box that is mostly empty. As you have 60 sweeps in the same area, all bounding boxes
pile up leading
> to a very ineficient situation. By subdividing it, you get smaller, tighter,
bounding boxes that
> overlap less with each other.
Thanks, Alain! I do seem to remember reading something similar in another
post awhile back, but didn't remember the details. I'm going to try this
trick.
While I was experimenting with using sphere_sweeps for the vines, my first
attempt actually did have multiple spline segments making up each vine, as
you've described. But after doing such a test (and not realizing that it
might save render time) I deleted the code...thinking it was an ineffieient
way of generating a sphere_sweep!! Just goes to show that seemingly
odd bits of code should be archived for future thought!
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
