 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
I am working on a snow/icicle macro currently, and due to certain issues
that I have faced, my code has forked....which is not at all what I desire.
I have three problems. Two have been solved individually by the fork, but
must be integrated to be truly considered "resolved". The third, I haven't
any clue how to approach. I shall elucidate:
1) Icicles not "blobbing" together (solved in SnowTest_2)
The solution to this problem required that I estimate the size of the
bounding box resulting from the application of snow to an object X...but
resulted in initial blob placement insufficiencies.
2) Initial blob placement errors (solved in SnowTest_3)
The solution to this issue required the actual min/max extents of first
the initial object, and secondly of the union of the snowed on object and
the snow. This resulted in the inability to blob the icicles together as
found in nature.
3) Blobbing of the snow *and* the icicles. This is unresolved.
What I am left with, are essentially two issues:
A) How to integrate SnowTest_2 and SnowTest_3 so that the icicles both blob
together AND are positioned accurately, to be used in the solution to (B)
B) How to blob (A) with the initial snow.
As is, the parse time for my snow macro *with* icicles is 1 second in one
method, and slightly longer in the second.
I know that I am so close to the solution that it hurts, but I've been
looking at it so long I can't see the forest for the trees.
I will post the source files required to evaluate this issue in p.b.s-f
(same thread name), and successful contributors to the unified resolution of
these issues shall be credited in the final release....I'm almost there! :-D
To those who wish to assist, please comment any references to SnowTex0 and
Ice2 and uncomment the vector pigments within the snowTest and icicleTest
macros, to avoid long renders. I have included the snow texture include
file, just for S's and G's.
many thanks,
ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmm...no takers? :-p
ian
"[GDS|Entropy]" <gds### [at] hotmail com> wrote in message
news:499c6ec6$1@news.povray.org...
> Hello,
>
> I am working on a snow/icicle macro currently, and due to certain issues
> that I have faced, my code has forked....which is not at all what I
> desire.
>
> I have three problems. Two have been solved individually by the fork, but
> must be integrated to be truly considered "resolved". The third, I haven't
> any clue how to approach. I shall elucidate:
>
> 1) Icicles not "blobbing" together (solved in SnowTest_2)
> The solution to this problem required that I estimate the size of the
> bounding box resulting from the application of snow to an object X...but
> resulted in initial blob placement insufficiencies.
>
> 2) Initial blob placement errors (solved in SnowTest_3)
> The solution to this issue required the actual min/max extents of first
> the initial object, and secondly of the union of the snowed on object and
> the snow. This resulted in the inability to blob the icicles together as
> found in nature.
>
> 3) Blobbing of the snow *and* the icicles. This is unresolved.
>
> What I am left with, are essentially two issues:
> A) How to integrate SnowTest_2 and SnowTest_3 so that the icicles both
> blob together AND are positioned accurately, to be used in the solution to
> (B)
> B) How to blob (A) with the initial snow.
>
> As is, the parse time for my snow macro *with* icicles is 1 second in one
> method, and slightly longer in the second.
>
> I know that I am so close to the solution that it hurts, but I've been
> looking at it so long I can't see the forest for the trees.
>
> I will post the source files required to evaluate this issue in p.b.s-f
> (same thread name), and successful contributors to the unified resolution
> of these issues shall be credited in the final release....I'm almost
> there! :-D
>
> To those who wish to assist, please comment any references to SnowTex0 and
> Ice2 and uncomment the vector pigments within the snowTest and icicleTest
> macros, to avoid long renders. I have included the snow texture include
> file, just for S's and G's.
>
> many thanks,
> ian
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Hello,
>
> I am working on a snow/icicle macro currently, and due to certain issues
> that I have faced, my code has forked....which is not at all what I desire.
>
> I have three problems. Two have been solved individually by the fork, but
> must be integrated to be truly considered "resolved". The third, I haven't
> any clue how to approach. I shall elucidate:
>
> 1) Icicles not "blobbing" together (solved in SnowTest_2)
> The solution to this problem required that I estimate the size of the
> bounding box resulting from the application of snow to an object X...but
> resulted in initial blob placement insufficiencies.
>
> 2) Initial blob placement errors (solved in SnowTest_3)
> The solution to this issue required the actual min/max extents of first
> the initial object, and secondly of the union of the snowed on object and
> the snow. This resulted in the inability to blob the icicles together as
> found in nature.
>
> 3) Blobbing of the snow *and* the icicles. This is unresolved.
>
> What I am left with, are essentially two issues:
> A) How to integrate SnowTest_2 and SnowTest_3 so that the icicles both blob
> together AND are positioned accurately, to be used in the solution to (B)
> B) How to blob (A) with the initial snow.
>
> As is, the parse time for my snow macro *with* icicles is 1 second in one
> method, and slightly longer in the second.
>
> I know that I am so close to the solution that it hurts, but I've been
> looking at it so long I can't see the forest for the trees.
>
> I will post the source files required to evaluate this issue in p.b.s-f
> (same thread name), and successful contributors to the unified resolution of
> these issues shall be credited in the final release....I'm almost there! :-D
>
> To those who wish to assist, please comment any references to SnowTex0 and
> Ice2 and uncomment the vector pigments within the snowTest and icicleTest
> macros, to avoid long renders. I have included the snow texture include
> file, just for S's and G's.
>
> many thanks,
> ian
Just an idea but would it be possible to make an array containing the positions
of the blobs for the icicles and the snow. Then using this array make a single
blob using all of these positions. I`m afraid I didn`t look at the code yet so
if this makes absolutely no sense, please forgive me.
Bridgeofstraws
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've since done that, and have used as input to the icicle macro I have used
the successful tests of the snow macro, thus limiting the input of invalid
vectors to the icicle macro, and reducing falied tests.
The only issue that this has created has been arrays of unknown length,
which are difficult to loop against.
ian
"Bridgeofstraws" <bri### [at] inboxcom> wrote in message
news:web.49a2001f783ea6738ce5254b0@news.povray.org...
> "[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>> Hello,
>>
>> I am working on a snow/icicle macro currently, and due to certain issues
>> that I have faced, my code has forked....which is not at all what I
>> desire.
>>
>> I have three problems. Two have been solved individually by the fork, but
>> must be integrated to be truly considered "resolved". The third, I
>> haven't
>> any clue how to approach. I shall elucidate:
>>
>> 1) Icicles not "blobbing" together (solved in SnowTest_2)
>> The solution to this problem required that I estimate the size of the
>> bounding box resulting from the application of snow to an object
>> X...but
>> resulted in initial blob placement insufficiencies.
>>
>> 2) Initial blob placement errors (solved in SnowTest_3)
>> The solution to this issue required the actual min/max extents of
>> first
>> the initial object, and secondly of the union of the snowed on object and
>> the snow. This resulted in the inability to blob the icicles together as
>> found in nature.
>>
>> 3) Blobbing of the snow *and* the icicles. This is unresolved.
>>
>> What I am left with, are essentially two issues:
>> A) How to integrate SnowTest_2 and SnowTest_3 so that the icicles both
>> blob
>> together AND are positioned accurately, to be used in the solution to (B)
>> B) How to blob (A) with the initial snow.
>>
>> As is, the parse time for my snow macro *with* icicles is 1 second in one
>> method, and slightly longer in the second.
>>
>> I know that I am so close to the solution that it hurts, but I've been
>> looking at it so long I can't see the forest for the trees.
>>
>> I will post the source files required to evaluate this issue in p.b.s-f
>> (same thread name), and successful contributors to the unified resolution
>> of
>> these issues shall be credited in the final release....I'm almost there!
>> :-D
>>
>> To those who wish to assist, please comment any references to SnowTex0
>> and
>> Ice2 and uncomment the vector pigments within the snowTest and icicleTest
>> macros, to avoid long renders. I have included the snow texture include
>> file, just for S's and G's.
>>
>> many thanks,
>> ian
>
> Just an idea but would it be possible to make an array containing the
> positions
> of the blobs for the icicles and the snow. Then using this array make a
> single
> blob using all of these positions. I`m afraid I didn`t look at the code
> yet so
> if this makes absolutely no sense, please forgive me.
>
> Bridgeofstraws
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> The only issue that this has created has been arrays of unknown length,
> which are difficult to loop against.
How can an array be of unknown length in POV?
You always have dimension_size() to give you the actual size of any array, or am
I misunderstanding you?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I pulled the array topic into its own thread, as it was more appropriate.
But since you asked: I am defining the array outside of a macro, populating
it within an if conditional (lets just say inside() for sake of discussion),
and then subsequently loop through the array inside of another macro, to
place objects..
So what happens is when I define the array to be say, 50, outside of the
first function, the inside test might not return 50 valid positions with
which to populate the array, in one instance resulting in an array of
dimension_size 50 with only 28 valid populated values.
I used a counter within the if conditional to verify this.
This is all a consequence of various workarounds needed due to SDL array
scope implementation, or you could say because of a lack of List<T>
functionality as found in C#.
I think more common programming language functionality would do a lot to
expand the capabilities of SDL.
ian
"clipka" <nomail@nomail> wrote in message
news:web.49a3a441783ea673a5bc7c50@news.povray.org...
> "[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
>> The only issue that this has created has been arrays of unknown length,
>> which are difficult to loop against.
>
> How can an array be of unknown length in POV?
>
> You always have dimension_size() to give you the actual size of any array,
> or am
> I misunderstanding you?
>
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> So what happens is when I define the array to be say, 50, outside of the
> first function, the inside test might not return 50 valid positions with
> which to populate the array, in one instance resulting in an array of
> dimension_size 50 with only 28 valid populated values.
>
> I used a counter within the if conditional to verify this.
In such cases, I usually go for all the 50 hits, not increasing the loop
variable on a miss.
But having thought about the array problem, I happened to find something that I
guess will be a head-slapper for you. It was for me. See other thread.
> I think more common programming language functionality would do a lot to
> expand the capabilities of SDL.
Yeah, the SDL definitely needs a rework.
> >> The only issue that this has created has been arrays of unknown length,
> >> which are difficult to loop against.
So that is what you meant. Heck, you young people are so spoilt with OO
languages... :) When I was young, array sizes were *always* of fixed length...
BTW, strictly speaking we're not talking about a problem of unknown array
length, but undefined elements...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
