using structure to represent a tree.

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 01 January 2009   #1
using structure to represent a tree.

would appreciate how one would go about doing this.

1.I have a tree which is represented with base(cylinder) and top(cone)
2.i wanted to pass a modifier to any part(top or base) so i'd like to be able to refer to each part with it's logical name.
3.Representing this in a structure "seams" ideal.

Problem is when i declare a variable of the struct type i assume it should be fool proof and not be able to be overwritten with any other data.

struct tree (treeBase = ( cylinder() ), treeTop = ( cone() ))--declare

tree_01=tree() --create tree object"testTree" --some tests to see if all is good
addmodifier tree_01.treeTop (bend()) --all ok so far.
tree_01.treeTop="foolProof" --why am i being allowed to change the contents of this

How can i prevent my self from overwriting the contents(members) of my tree_01 object.

Thanks a bunch.

Old 01 January 2009   #2
Protected, private and public members are features available only when writing a class, not in a struct. And unfortunately, maxscript is not oo, so no classes in here.
Same is the case if you program in C. These features are available in a C++ like OO language. The member variables cannot be privatized/protected. But you can kindof protect your functions:
struct tree 
		theTop= undefined,
		theBase = undefined,
		fn treeBase = 
				theBase = cylinder() 
		fn treeTop = 
			theTop = cone() 
		fn initTree =
Old 01 January 2009   #3
while on the topic of struct, it'd be great if there could be some enhancement to structs in one of the future releases ... public/private in a maxscript struct ? That would be awesome

Last edited by shibumenon : 01 January 2009 at 01:07 PM.
Old 01 January 2009   #4
Thumbs up

Thanks shibu

I'm surely overlooking something in your design as far as intended use.
Because i can still create a variable called
tree_01.theTop="foo" and ruin everything

I'll embarrass my self once again:
Would python help here ???

Old 01 January 2009   #5
You can't protect a MXS struct variable from direct modification, as achoo said. There are no access modifiers in the language. You have to do it by convention: eg. "I'm private" naming ( _base, _top ) for member variables, and the provision of accessors ( getBase(), setBase()) etc. Most clients will understand the initial underscore means "hands off".

Last edited by drdubosc : 01 January 2009 at 01:51 PM.
Old 01 January 2009   #6
hmmm ... interesting.
one twisted workaround would be this :
write your tree struct and come up with some really abstract unthinkable name for the top and base members.
struct tree 
 		gobledeeeGookTheTop= undefined,
 		gobledeeeGookTheBase = undefined,
 		fn treeBase = 
 				gobledeeeGookTheBase = cylinder() 
 		fn treeTop = 
 			gobledeeeGookTheTop = cone() 
 		fn initTree =
 		fn getTop =
 			return gobledeeeGookTheTop;
 		fn getBase =
 			return gobledeeeGookTheBase
 		makeTree = initTree()

Now make sure that your maxscript file has only the above struct , encrypt your script and make the encrypted version available to the next level of developer.
Also, create a second struct, kind of a wrapper struct, thro which the next level of developer can access your tree struct

	struct treeMaker
 		tree_01=tree(), --create tree object
 		fn getBase = tree_01.getTop(),
 		fn getTop = tree_01.getBase()
 	myTree = treeMaker()
 	varr1 =myTree.getBase()

Last edited by shibumenon : 01 January 2009 at 01:50 PM.
Old 01 January 2009   #7
This rabbit hole doesn't seam to end
Thanks again shibu.

Old 01 January 2009   #8
yes, it doesn't end !
This is not really as foolproof as we'd like.
If you really want to crack it, you can use
sss = getPropNames tree

to figure out whats there in the hidden struct !!

or better still, just do some buggy code with the tree struct, and
maxscript promptly hands out the entire structure of your hidden struct to you in red on to the listener as an error

Last edited by shibumenon : 01 January 2009 at 03:44 PM.
Old 01 January 2009   #9
Let's face it, MXS is for scripting, not heavy-duty programming? Access modifiers, inheritance, and so forth, only really come into their own in larger, or more collaborative projects, especially when writing compiled libraries, IMO, although I often miss the way of thinking that would come with full-featured OO, and it would make community-written libraries easier to produce. It would be lovely if the SDK was easier to write to, but maybe that's just me being hopeless .
Old 01 January 2009   #10
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 01:03 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.