Hi Michael,

I'm not sure of everything that you have in mind for Groups.

Would it be possible to add an auto number option for Objects to the array tool and/or Ctrl Copy?

This is the result that would be nice to achieve:

Hi Steve,

> I'm not sure of everything that you have in mind for Groups.

Well, one of the tricky areas for groups that still needs to be resolved is how the behavior works for copying things. I'm actually not that confident that particular area of groups is going to be all ironed out by the end of v2, it will probably need some tuning into v3.


> Would it be possible to add an auto number option for Objects
> to the array tool and/or Ctrl Copy?

I've tried so far to avoid automatically naming things, so that the scene browser won't just get filled up with a bunch of names and drown out the stuff you are actually interested in. So that's why there aren't things automatically assigned names like "Curve#1", "Curve#2" etc...

But if I understand correctly, in this case you're talking about an object that has started out with an existing name and you want to have its number bumped up. That sounds more reasonable, but I'm still kind of worried about mutating object properties by default...

Maybe a good solution for the time being would be a script that you could set up on a keyboard shortcut. Then you could press that shortcut key after making duplicates and the script would bump up the numbers on the duplicated objects. Does that sound like it would work?

- Michael

Sounds good Michael!

I use the OBJ export most often and I'm finding if I have multiple objects named Chair,
then they need to be separated in my poly modeler on import which destroys the hierarchy.

I was thinking in terms of something like this:



But I'll take what I can get. :)

Hi Steve,

> I was thinking in terms of something like this:

You mean just adding it to the Array Dir command and not to anything else?

That's sort of hard to justify making just one array command have that special option and not other methods...

Then the problem with that is there are 4 different array commands, plus the Transform/Copy command, plus using Copy+Paste, plus using Ctrl+Drag on an object...

So that's kind of a lot of different areas to add some additional option like this into - some of them like Copy/Paste or Ctrl+Drag don't even have any additional UI showing up for them currently, so that could maybe mean adding in an additional stage to it to make that checkbox show up...

These are some of the issues that can tend to make it more difficult than it seems at first to just add in "one little option" ... ;)


> I use the OBJ export most often and I'm finding if I have
> multiple objects named Chair, then they need to be separated
> in my poly modeler on import which destroys the hierarchy.

You may be able to solve this without re-numbering actually, try going to Options > Import/Export, and uncheck "Combine same named objects" which is at the top:



Does that make the objects individually addressable by your poly modeler, or do you still have the same problem?

- Michael

Hi Steve, here is an "object name separator" script that may be useful if that other option does not help:

script:var Objects = moi.geometryDatabase.getObjects(); var Names = new Object(); for ( var i = 0; i < Objects.length; ++i ) { var Obj = Objects.item(i); if ( Obj.name == '' ) { continue; } if ( !Names[Obj.name] ) { Names[Obj.name] = new Array(); } Names[Obj.name].push( Obj ); } for ( var Name in Names ) { if ( Names[Name].length == 1 ) { continue; } for ( var i = 0; i < Names[Name].length; ++i ) { Names[Name][i].name = Name + '_' + (i+1); } }


Copy that whole thing above and paste it in as the Command part of a new shortcut key under Options> Shortcut keys.

That will add numbers to the names of any duplicate objects.

It just sticks numbers at the end of the name though, so for example if you have 5 objects all named "Blah", after you run the script you will instead have Blah_1, Blah_2, Blah_3, Blah_4, Blah_5. So don't put the number into the original name, the script will add the numbers.


This method should work to separate the names no matter how you duplicated the objects, whether it was by array, copy/paste, importing another file, transform/copy, rotate with copy option, Ctrl+drag, whatever...

- Michael

Hi Michael,

>You mean just adding it to the Array Dir command and not to anything else?

>That's sort of hard to justify making just one array command have that special option and not other methods...

Well no, I was using that as an example.

>You may be able to solve this without re-numbering actually, try going to Options > Import/Export, and uncheck "Combine same named >objects" which is at the top:

Tried that some time ago, Same problem.

I guess what I'm getting at is Nested Hierarchy. I did another gif screen cap to show an example. I won't embed it as it may be
a little large for some. It also shows the result of the "object name separator" script you provided (Thanks).

This is why I mentioned Groups in my 1st post, my purpose being more as an open discussion, than a quick fix. Hope you understand. :)

Hi Steve,

> Well no, I was using that as an example.

So the problem then is having so many different possible ways to copy things - I mean just off the top of my head:

1. Array
2. ArrayDir
3. ArrayCircular
4. ArrayCurve
5. Transform/Copy
6. Rotate with "Make copies" option
7. Rotate axis with "Make copies" option
8. Scale with "Make copies" option
9. Scale2D with "Make copies" option
10. Scale1D with "Make copies" option
11. Mirror with "Delete input objects" disabled,
12. Edit/Paste (from clipboard)
13. the new "PastePart" command
14. File/Import
15. the new ImportPart command,
16. Ctrl+Drag on an object,
17. Ctrl+drag on the edit frame's rotation grip,
18. ctrl+drag on the edit frame's scaling corner.

That's what I can think of right now... So it's like you're talking about adding in something like 18 checkboxes into the UI - that's why it's not such a simple thing to add in.

It doesn't take too many of these kinds of options to be added in to 18 places in the UI before the UI becomes pretty full of stuff!


> Tried that some time ago, Same problem.

Which mesh program are you bringing this into by the way?



> I guess what I'm getting at is Nested Hierarchy.

Yeah, that will definitely be more of what Groups will be intended to do.

However, I don't think that it is going to be possible to export group hierarchies into every kind of polygon mesh export format - for example OBJ in particular does not have anything set up in it to have an actual parent/child hierarchy between different objects.


> It also shows the result of the "object name separator" script
> you provided (Thanks).

Does that script help you solve the immediate problem?

In your screencap, I noticed that you set all the pieces of your second copied object to the same name - doesn't that end up messing up your organization? If you don't do that name assigning step then you should get your pieces preserved better, like the legs will be named "Legs_1" for the first legs, and "Legs_2" for the second chair's legs, wouldn't that be more what you want?

- Michael

Hi Michael,

Sorry, I'm guilty of side tracking this discussion into a
parent/child hierarchy between different objects wish. ;)
Does fbx, dae, or lwo support parent/child hierarchy?

>In your screencap, I noticed that you set all the pieces of your second copied object to the same name - doesn't that end up messing up your organization? If you don't do that name assigning step then you should get your pieces preserved better, like the legs will be named "Legs_1" for the first legs, and "Legs_2" for the second chair's legs, wouldn't that be more what you want?<


When I run the script on (1) chair object I end up with
chair_1 to chair_12. So I guess the way I'm going to
get what I need is if each instance of a chair is single
Boolean object. Then I can run the script on multiple chairs
in get the desired result. Then I can use the Style setting
to zero in on sub-objects using 'Select by material' in my
mesh program.

I use trueSpace 6.6/76.1 as my main mesh program (I know, the program
people love to hate, but it works for me.)

I'm open to alternatives for a poly render-er if it makes life easier.


Thanks very much for auto numbering script!!! :)

Hi Steve,

> Does fbx, dae, or lwo support parent/child hierarchy?

lwo does, and I think that fbx and dae probably do as well.

But keep in mind that just because a format supports having a hierarchy does not automatically mean that a program reading it also preserves it as well.

I'm not really sure in general if I'll be able to attempt to get groups exporting to other programs in MoI v2, that may be something that does not happen until v3.

I'll actually be kind of lucky to get groups just working well within MoI itself for v2 I think. Exporting tends to be a whole different world of difficulty.


> When I run the script on (1) chair object I end up with
> chair_1 to chair_12.

Sorry, I'm not following you - it seemed like in your screencap you did not just have a "chair" object, you had a variety of objects like "Legs", "Pole" etc...

So now I'm confused that you are talking about "chair" - what happened to all the individual pieces?

Maybe you can post your chair model so I can follow along more closely.

But the idea is that if you have a bunch of objects like "Legs", "Pole", "Seat", etc.., then if you duplicate all of those and run that script (without changing or assigning a new name to everything!) then you should end up with the legs on object1 being "Legs_1", the legs on object 2 being "Legs_2", etc... - does that not work for you?

- Michael

Here's the file.

Thanks for posting the model.

So yeah if I take your chair model and make some copies it looks like this:



You've got the duplicate names there that you don't want - like "Foot rest" for example is the same name on all 3 foot rests.

But why at this point in your screencap are you selecting the copied objects and setting all their names to something like "chair1" ? That is not making a hierarchy - what that is doing is erasing all the existing names on all the selected objects and instead setting them to have the name "chair1".

It doesn't seem like you want to do that - you're erasing all your assigned names by doing that.

Instead right after copying, run the script (do not assign any new names), and the object names will separate like this:



So now you've got different names for each foot rest - the foot rest for object 1 is "Foot rest_1", the foot rest for object 2 is "Foot rest_2", and the foot rest for object 3 is "Foot rest_3".

Doesn't that do what you need?

- Michael

My ideal situation would be I load say 20 chairs via OBJ import and 1st step down in hierarchy
would select one of 20 chairs, next step down would select that chairs seat etc. (parent/sibling nesting)
without thinking about the fact that OBJ doesn't support parent/sibling nesting.

The script you supplied will be very handy for using multiple approaches.

Thanks again!!

> My ideal situation would be I load say 20 chairs via OBJ
> import and 1st step down in hierarchy
> would select one of 20 chairs, next step down would
> select that chairs seat etc. (parent/sibling nesting)

Well yes I think we will get to that point eventually with groups.

Except OBJ not supporting hierarchy throws a monkey wrench in there.

In some cases I have seen programs encode a hierarchy inside of an object name with stuff like different levels separated by a : like the name being "Chair1:Seat:Seat Top"

Do you happen to know if trueSpace supports converting object names into a hierarchy like that? If it does then it may be possible to make it work.

What happens if you take a model that has hierarchy in trueSpace, and export it to OBJ and then read it back in again to a new fresh trueSpace program instance? Do you get the hierarchy back again or is it gone? If you get it back again, if you can send me a sample OBJ file that preserves the hierarchy then that could help.

- Michael

>What happens if you take a model that has hierarchy in trueSpace, and export it to OBJ and then read it back in again to a new fresh
>trueSpace program instance? Do you get the hierarchy back again or is it gone?

No, it's maintained for 1 chair, that was the flaw in my thinking.

If Moi gets to this point and there is another viable export option,(fbx, dae,lwo) then it's time to shop for a new poly modeler.

For the moment the attached chair works, I can use your script on multiple copies (giving me chair_1 Chair_2 etc.), export as obj and
select down in hierarchy and from there I can select by Style (material).

Hi Steve, I'm glad you got a way that will work for the time being.

So the test I was asking about was actually: What happens if you create a model just totally inside of trueSpace instead of importing it from MoI, where that model has some hierarchy in it (for example a parent box with 2 child spheres, or whatever).

If you export that model from trueSpace into an OBJ file, and then exit trueSpace, then start it up again and read the OBJ file back in, do you end up with the hierarchy preserved?

If you do, then it means that trueSpace is encoding its hierarchy somehow in the OBJ file and if that is the case then I could do it too.

- Michael

Danperk, how did you create the awesome animated GIF in the first post? It looks very clean and noise-free.

Hi Ecuadorian,

I used Camtasia 5. Not sure what version they are selling
now but Version 5 worked well so I haven't upgraded.


Hi Michael,

I tried the round trip by exporting a parent with 2 sibling children.

On import the group reverted to 3 siblings.

My main problem is I'm using Moi for scene creation, not just for
creating objects. It works so well for this, I prefer to do everything
except textures and render/animation in Moi. The situation is that
after the texturing stage if a client decides to make changes to
the scene layout, (they always do), then I need my hierarchy to
be easy to re-arrange/edit on the textured version.

That is why I'm interest other poly software with good import choices
that Moi hopefully will support in the future.

Carrara works very well with many of the file types exported by MoI, including 3dm

Certainly it is good value and easy to learn but it comes with so much "built in" operations that other high priced apps often charge huge plugin money for.


Brian

Hi Steve, thanks for running that test. So it looks like OBJ will not work for preserving hierarchies into trueSpace (and probably other programs also).

> That is why I'm interest other poly software with
> good import choices that Moi hopefully will support in the future.

Yeah I will probably be able to focus on this early in the v3 timeframe.

File formats tend to be a finicky area of work, some programs are pretty sensitive to a variety of factors.

It's just not such a great area to tinker with to a very large degree right near the end of a beta period, just too much possibility of problems being introduced.

- Michael

Hi Brian,

> Carrara works very well with many of the file types exported by MoI, including 3dm

> Certainly it is good value and easy to learn but it comes with so much "built in" operations that other high priced apps often charge huge plugin money for.

I have Carrara Pro 6.2 which I got free from 3DArtist Magazine. It's OK and I like to have lots of options for file conversion etc.,
but I think that for most people, myself included, we tend to judge/compare software with what we know and are used to, so for
me Carrara is just not a good fit. In what I have learned by researching 3D programs available out there, I think Modo has the
most to offer for my requirements. But thanks for the suggestion!!

Hi Michael,

> So it looks like OBJ will not work for preserving hierarchies into trueSpace (and probably other programs also).

Yeah it looks that way, still in most regards OBJ export allows me to get the data across and the rest is just optimizing my set-up
to make working in my poly prog. as painless as possible.

I did some testing with Right Hemisphere Deep View, (an excellent free utility), to see some results of Moi's different exports.
Now I realize these results are dependent on Deep View's import parser but interesting anyway. You can view the scene tree or
a parts list, (which seems to relate to the Object settings in Moi.) I won't list all my result but FBX was interesting in that the parts
were arranged as instances.



> File formats tend to be a finicky area of work, some programs are pretty sensitive to a variety of factors.

> It's just not such a great area to tinker with to a very large degree right near the end of a beta period, just too much possibility of problems being introduced.

As I said I wanted this more as a discussion, to pick your brain, not to try and squeeze more things into Ver. 2. :)

Thanks for the script, and your patience!! :)