 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No, you can't #declare a blob component. I don't know what you want to
do but maybe following helps: you can make a #macro that inserts blob
componets into a blob{}.
----
#macro make_blob()
sphere{my_pos,my_radius,1 [translate ....]}
cylinder{my_pos,my_radius,0.5 [translate ....]}
#end
blob{
#declare my_pos=3;
#declare my_radius=0.5;
make_blob()
#declare my_pos=<2,1,2>;
#declare my_radius=.2;
make_blob()
}
----
Michael Andrews wrote:
>
> Hi Folks,
> Well I think the subject says it all; is it possible to #declare a
> blob component? I was trying to declare an array of them, but couldn't
> work out how it could be done, if it could be done.
> Any ideas, or is this a total non-starter? Are blob components the
> only syntactic structures that _can not_ be #declared? Maybe this in the
> FAQ or documentation and I'm just making a fool of myself ...
>
> All coments gratefully recieved :-)
> Mike Andrews.
--
---------------------------------------------------
visit my homepage:
http://www.geocities.com/SiliconValley/Pines/7992/
the POVRay Objects Collection:
http://twysted.net/povobj/
---------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Michael Andrews wrote:
> Well I think the subject says it all; is it possible to #declare a
> blob component?
I've got some code to do this - I'm just giving it some final testing
and bug-fixing and then I'm going to send it to Chris Young for
inclusion in the next version. I've already discussed this with him and
he's keen to add this feature as well.
My code allows you to do something like this:
#declare Blob1 =
blob {
sphere {...}
cylinder {...}
... // more components, textures, transforms...
}
#declare Blob2 =
blob {
sphere {...}
cylinder {...}
blob {Blob1} // incorporate blob1 here!!!
... // etc... more components or more 'included' blobs
}
It allows all textures and transformations in the same way as CSGs are
handled, and it handles multi-textured blobs in a simple, logical
fashion. Textures can be specified either in Blob1, Blob2, both or
neither. So this is legal...
#declare Blob1 =
blob {
sphere {...}
cylinder {...}
...
}
#declare Blob2 =
blob {
blob {Blob1 texture {...}} // incorporate blob1 here!!!
blob {Blob1 texture {...} scale <-1, 1, 1>} // mirror blob1 here!!!
}
And it allows these sorts of constructs, just like CSG unions, to group
components and transform them collectively...
blob {
sphere {...}
cylinder {...}
blob {
sphere {...}
cylinder {...}
translate ... scale ...
}
translate ... scale ...
}
Blobs can be 'nested' to whatever depth time and memory permit.
Although it doesn't actually allow you to #declare a single component
itself, you can always #declare a blob that contains just one component,
and then use that #declared component anywhere just like in the example
above.
And I thought I was the only person in the world who wanted to use such
a feature!
I'd like some feedback on whether the above syntax examples are
sufficient, and what sorts of deficiencies it might have... I guess it's
best to get this sorted out fully before it's merged into POV itself!
Cheers, and merry POVing to all,
Darius Davis
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darius Davis wrote:
> Michael Andrews wrote:
>
> > Well I think the subject says it all; is it possible to #declare a>
> blob component?
[snip]
>
> And it allows these sorts of constructs, just like CSG unions, to group
> components and transform them collectively...
>
> blob {
> sphere {...}
> cylinder {...}
> blob {
> sphere {...}
> cylinder {...}
> translate ... scale ...
> }
> translate ... scale ...
> }
>
> Blobs can be 'nested' to whatever depth time and memory permit.
>
[snip]
> I'd like some feedback on whether the above syntax examples are
> sufficient, and what sorts of deficiencies it might have... I guess it's
> best to get this sorted out fully before it's merged into POV itself!
>
> Cheers, and merry POVing to all,
>
> Darius Davis
Hi Darius,
Great stuff! I hadn't thought of writing a patch to do the job this way
... looks logical now I see it.
It was really the last syntax form that I was trying to achieve with arrays
of blob components - rotate/translate a batch of components, attach to another
rotated/translated batch of components, attach rotate ... etc, etc.
I do hope this gets approved for inclusion in the next release - possibly
let Ronald Parker have the alterations to include in the SuperPatch?
Thanks for the reply,
Mike Andrews.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
A definate "Yes" to the idea of nested blobs.
Didn't think it possible.
Also, I didn't realize before that a single component could be used, not that
its useful.
Message <363### [at] NO SPAMTHANKSacmorg>, Darius Davis typed...
>
>Michael Andrews wrote:
>
>> Well I think the subject says it all; is it possible to #declare a
>> blob component?
>
>I've got some code to do this - I'm just giving it some final testing
>and bug-fixing and then I'm going to send it to Chris Young for
>inclusion in the next version. I've already discussed this with him and
>he's keen to add this feature as well.
>
>My code allows you to do something like this:
>
>#declare Blob1 =
>blob {
> sphere {...}
> cylinder {...}
> ... // more components, textures, transforms...
>}
>
>#declare Blob2 =
>blob {
> sphere {...}
> cylinder {...}
> blob {Blob1} // incorporate blob1 here!!!
> ... // etc... more components or more 'included' blobs
>}
>
>It allows all textures and transformations in the same way as CSGs are
>handled, and it handles multi-textured blobs in a simple, logical
>fashion. Textures can be specified either in Blob1, Blob2, both or
>neither. So this is legal...
>
>#declare Blob1 =
>blob {
> sphere {...}
> cylinder {...}
> ...
>}
>
>#declare Blob2 =
>blob {
> blob {Blob1 texture {...}} // incorporate blob1 here!!!
> blob {Blob1 texture {...} scale <-1, 1, 1>} // mirror blob1 here!!!
>}
>
>And it allows these sorts of constructs, just like CSG unions, to group
>components and transform them collectively...
>
>blob {
> sphere {...}
> cylinder {...}
> blob {
> sphere {...}
> cylinder {...}
> translate ... scale ...
> }
> translate ... scale ...
>}
>
>Blobs can be 'nested' to whatever depth time and memory permit.
>
>Although it doesn't actually allow you to #declare a single component
>itself, you can always #declare a blob that contains just one component,
>and then use that #declared component anywhere just like in the example
>above.
>
>And I thought I was the only person in the world who wanted to use such
>a feature!
>
>I'd like some feedback on whether the above syntax examples are
>sufficient, and what sorts of deficiencies it might have... I guess it's
>best to get this sorted out fully before it's merged into POV itself!
>
>Cheers, and merry POVing to all,
>
>
>Darius Davis
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.html
=Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What is the interpretation of the following ?
Dan
#declare Blob1 =
blob {
sphere {...}
cylinder {...}
... // more components, textures, transforms...
threshold 0.5
sturm
}
blob {
sphere {...}
cylinder {...}
blob {Blob1}
}
--
http://www.flash.net/~djconnel/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been wanting to do this for a long time, really!
Consider this (can your code handle this?):
#declare Blob1 =
blob {
threshold .3
sphere {<0, 0, 0>, 1, 1}
pigment {color White}
}
#declare Blob2 =
blob {
threshold .3
sphere {<0, 0, -1>, 1, 1}
pigment {color Blue}
}
blob {
blob {Blob1 translate 1*clock*y}
blob {Blob2 rotate 30*clock*y}
}
Now imagine if you built a bunch of parts for a human using blobs and declared
each one, then incorporated each part into another one. You could move the
parts to make the character walk and talk ect. Considering that making, for
example, an arm with blobs can take 30 or more components, having to tranform
each one individually is a real pain. With this syntax, each blob would be
just like any other primitive, yet they could interact with other blobs, which
would be cool.
I think it'll be great. Glad to hear that Chris Young likes the idea.:)
-Mike
Darius Davis wrote:
> Although it doesn't actually allow you to #declare a single component
> itself, you can always #declare a blob that contains just one component,
> and then use that #declared component anywhere just like in the example
> above.
>
> And I thought I was the only person in the world who wanted to use such
> a feature!
>
> I'd like some feedback on whether the above syntax examples are
> sufficient, and what sorts of deficiencies it might have... I guess it's
> best to get this sorted out fully before it's merged into POV itself!
>
> Cheers, and merry POVing to all,
>
> Darius Davis
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> What is the interpretation of the following ?
>
> Dan
>
[ code snipped to end of message ]
Hi,
I forgot to state this in my original post... when a 'sub-blob' is
included in another blob with a different threshold, the sub-blob
component strengths are modified so that the *shape* of the sub-blob is
not changed. (I figured that would be the most useful way of
interpreting this situation) It uses the threshold values of both the
sub-blob and the 'parent' blob to perform that computation. So in the
example below, the components of Blob1 (defined with threshold 0.5) are
merged into the second blob with their strengths doubled (I think), so
they appear 'the same' in the render. I hope I've explained this well
enough... it's pretty complicated and it's been a few weeks since I
looked at the code in any detail.
Regarding the 'sturm' flag... I hadn't even thought of it. :)
I guess we could set the 'sturm' flag for the blob if any sub-blobs it
contains have sturm set. Does this sound reasonable? Unfortunately, my
implementation actually merges the *components* of the sub-blob into the
new blob, so it's not possible to have 'parts' of the blob 'sturm'ed in
the way the code below implies.
The same could also go for the 'heirarchy' flag perhaps - set
'heirarchy' if any of the sub-blobs have the 'heirarchy' flag set.
If anyone has any other suggestions for any sort of implementation of
these flags, I'll try my hardest to code it. Once again, it's best to
get the syntax and semantics all fully specified before anything
'official' happens.
Cheers,
Darius Davis
> #declare Blob1 =
> blob {
> sphere {...}
> cylinder {...}
> ... // more components, textures, transforms...
> threshold 0.5
> sturm
> }
>
> blob {
> sphere {...}
> cylinder {...}
> blob {Blob1}
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike wrote:
> I've been wanting to do this for a long time, really!
>
> Consider this (can your code handle this?):
>
> #declare Blob1 =
> blob {
> threshold .3
> sphere {<0, 0, 0>, 1, 1}
> pigment {color White}
> }
>
> #declare Blob2 =
> blob {
> threshold .3
> sphere {<0, 0, -1>, 1, 1}
> pigment {color Blue}
> }
>
> blob {
> blob {Blob1 translate 1*clock*y}
> blob {Blob2 rotate 30*clock*y}
> }
In a word, yes. I can't see anything there that would cause a problem.
The translates and rotates on sub-blobs all work OK, I've tested this
extensively.
> Now imagine if you built a bunch of parts for a human using blobs and declared
> each one, then incorporated each part into another one. You could move the
> parts to make the character walk and talk ect.
The only problem is that each sub-blob component interacts with *every*
other... it's not possible to limit the interactions between
components, even if the components are within different 'sub-blobs' - at
least, it's not possible in any way I can see :) So, if you move two
blobbed hands together, they'll interact in the same way that blobs
normally do if they both have the same ultimate 'parent' blob. I've
thought long and hard about this and I can't think of any way to prevent
it. (But I'm not going to stop thinking about it yet... ;)
> I think it'll be great.
Well, I've already had some great fun with it! I think it's great, and
it'd be my personal pleasure to share it with all!
Cheers,
Darius Davis
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Makes a person wonder if a negative strength sort of thing could be applied
which would only affect surfaces external to the parent/sub group.
As in the interaction of a finger into a palm of a hand both made of separate
blob parent objects.
Just thought everyone might like to dream along with.
Actually there is kind of a way of doing this already.
Two identical blob groups; one positive, other negative strength. The two
don't interact with each other but the surface to deform interactively needs
to be a part of the positive strength blob group, the negative strength blob
group would need to be minus that "touched" surface.
Message <363### [at] BEGONEVILESPAMMERSacmorg>, Darius Davis typed...
>
>Mike wrote:
>> I've been wanting to do this for a long time, really!
>>
>> Consider this (can your code handle this?):
>>
>> #declare Blob1 =
>> blob {
>> threshold .3
>> sphere {<0, 0, 0>, 1, 1}
>> pigment {color White}
>> }
>>
>> #declare Blob2 =
>> blob {
>> threshold .3
>> sphere {<0, 0, -1>, 1, 1}
>> pigment {color Blue}
>> }
>>
>> blob {
>> blob {Blob1 translate 1*clock*y}
>> blob {Blob2 rotate 30*clock*y}
>> }
>
>In a word, yes. I can't see anything there that would cause a problem.
>The translates and rotates on sub-blobs all work OK, I've tested this
>extensively.
>
>> Now imagine if you built a bunch of parts for a human using blobs and
declared
>> each one, then incorporated each part into another one. You could move the
>> parts to make the character walk and talk ect.
>
>The only problem is that each sub-blob component interacts with *every*
>other... it's not possible to limit the interactions between
>components, even if the components are within different 'sub-blobs' - at
>least, it's not possible in any way I can see :) So, if you move two
>blobbed hands together, they'll interact in the same way that blobs
>normally do if they both have the same ultimate 'parent' blob. I've
>thought long and hard about this and I can't think of any way to prevent
>it. (But I'm not going to stop thinking about it yet... ;)
>
>> I think it'll be great.
>
>Well, I've already had some great fun with it! I think it's great, and
>it'd be my personal pleasure to share it with all!
>
>Cheers,
>
>Darius Davis
--
omniVERSE: beyond the universe
http://members.aol.com/inversez/POVring.html
=Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <363### [at] BEGONEVILESPAMMERSacmorg>, Darius Davis
<Dar### [at] BEGONEVILESPAMMERSacmorg> wrote:
>The only problem is that each sub-blob component interacts with *every*
>other... it's not possible to limit the interactions between
>components, even if the components are within different 'sub-blobs' - at
>least, it's not possible in any way I can see :) So, if you move two
>blobbed hands together, they'll interact in the same way that blobs
>normally do if they both have the same ultimate 'parent' blob. I've
>thought long and hard about this and I can't think of any way to prevent
>it. (But I'm not going to stop thinking about it yet... ;)
Would it be possible and reasonable to assign 'groups' to blob components,
and then specify which groups can interact (or perhaps more appropriately,
cannot interact) with which other groups?
So that groups 'left arm' and 'right arm' can interact with only the
'shoulder' group. 'Shoulder' can interact with only the 'neck' group,
'left arm' group, 'right arm' group, and 'chest' group. Etc.
The 'bullet' group can interact with any group except for the 'thick
skull' group...
Jerry
jer### [at] hoboescom
http://www.hoboes.com/jerry/ e-mail hel### [at] hoboescom
What Your Children Are Doing: http://www.hoboes.com/html/NetLife/Children/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
