Hi guys,
I just got molested by the numerous group bugs and I need a workaround.
I have 2 objects that I want in a group because I want to be able to click on them (and refer to them) as though they are 1 object. – There will be hundreds of these groups at the end (why this is important).
The most serious bug was that scripting movement of the groups results in almost random movement (mathematically incorrect).
I can easily attach them but the problem is the 2 objects need to have different colors (and attaching copies one color to the other).
This seems like it would be a common problem so is there an easy solution?
Link them and they can have different colors.
Also, search the forum about groups and workaraunds.
Try this and see if it works for what you need. The objects won’t be grouped but linked to a dummy, so they will act as a group when modifying the dummy.
try destroydialog ::RO_PSEUDO_GROUP catch()
rollout RO_PSEUDO_GROUP "Pseudo Group" width:200 height:72
(
button bt_group "Group Selection" pos:[8,32] width:184 height:32
editText et_groupName "Group Name:" pos:[9,8] width:183 height:16
on bt_group pressed do
(
if selection.count > 0 do
(
if et_groupName.text != "" then gname = et_groupName.text else gname = uniquename "group_" numDigit:3
g = dummy boxsize:(selection.max-selection.min) pos:selection.center name:gname
for j in selection where j.parent == undefined do j.parent = g
select g
)
)
)
createdialog RO_PSEUDO_GROUP
Hi again, I just woke and read the above responses.
Both the code pasted, and the solution on the linked thread work for scripting purposes however as said I also need to be able to click on them as 1 object (by clicking anywhere on the object).
[i]Using a dummy or boxgizmo on the extents would make the required functionality far too slow.
[/i]I can of course parent 1 to the other but then if I click the child there will be issues..
there are no bugs in ‘group mechanics’. if anything works unexpected for you it doesn’t mean works wrong.
‘group’ is exactly what you are looking for. you just need to use it right.
what’s wrong with groups you see?
Go into top view and create 2 planes next to each other.
Then create another object in the middle of each, and group those to the planes (so you have 2 groups next to each other).
Then try to get the left edge of the left group to line up with the right edge of the right group (with script).
[u]pseudo code:[/u]
Select left_group
move $ [(Right_group.max.x-Left_group.min.x),0,0]
This code works perfectly if they aren't in a group. It overshoots in an indecipherable way if within a group.
This is of course on top of the difficulties in dynamically selecting group names, and ridiculous things like not even being able to return a pos value (at least in a standard way).
EDIT:
Matter of fact you don’t even need to to use 2 objects for each and the right one doesn’t have to be a group. The moment you group the left object (even if only 1 object), that simple line of code has a bug (and overshoots).
as i understood your only problem is correctly get a bounding box of contained members of a group. so let’s focus on this issue.
as i said – there are no bugs in ‘groups’. there are a lot of bugs in max but the ‘group area’ is bugs-free
I just added an edit to the above (showing the group-move bug). - [i]It can't be anything else..
[/i]My problem is that I do need to be able to click the objects (that's a big part of the functionality of the script). There is a significant amount of extra time needed if you are trying to select a thin surrounding line (which adds up over time).
I could maybe parent one to the other and have dual values for everything in the "group" but that is messy in code (and I'd be amazed if there wasn't a better solution). -- [i]And if I accidentally select the child I'd have to re-select the parent (for things like scale).
[/i]
EDIT AGAIN:
Ok I just checked the pivot and it’s because the pivot moved away from the object when grouping it for some reason. If I’m going to keep using groups I’d need a way to center that to the object with code. – Nothing shows in the macroscript window if I manually do that though…
CORRECTION: Nope, moving it by script moves the pivot and the object in different distances (putting them out of alignment again/immediately).
group selection is a built-in max solution. it is possible to mimic this behavior with a custom solution but… why?
you can find on this forum a thread (maybe several posts in unrelated thread) where i showed now to use CA to ‘group’ nodes. the goal of this grouping was – delete whole group if any member was deleted. the solving this task makes the ‘sync-selecting’ an included option.