Author Topic: A proper component tree  (Read 7952 times)

0 Members and 2 Guests are viewing this topic.

Offline quigley

A proper component tree
« on: February 17, 2010, 03:26:23 am »
Complex objects are a nightmare without this. Need to be able to have an object tree that you can group objects inand apply material to the group, or show/hide objects. ideally the names would be taken from the imported CAD data and not just poly1, poly2 etc.

Offline Pedro_Julio

Re: A proper component tree
« Reply #1 on: February 19, 2010, 12:29:15 pm »
I'll put my 2 cents in and back this idea too.  It really would be fantastic to have a feature like this.  Hiding and unhiding things sequentially can be extremely tedious on more complex models.

Offline Tim

Re: A proper component tree
« Reply #2 on: February 20, 2010, 02:47:38 am »
Ditto - With even small assemblies hide and un-hide is difficult to work with.  I agree with pulling the names from the CAD tool.  Tree should mimic the CAD structure Top assmebly (group), sub assemblies, parts.

Offline jbeau

Re: A proper component tree
« Reply #3 on: February 20, 2010, 03:07:58 pm »
An object tree would be nice, as viewing and hiding objects has always been a pain with Hypershot. The ability to isolate parts or hide unselected/hide selected objects would be a nice addition to the UI. I would also like to have the ability to assign any key to a viewport function. This way, you can assign the same common keyboard shortcuts from other popular interfaces.
~Jbeau
« Last Edit: February 20, 2010, 03:10:23 pm by jbeau3d »

Offline timb

Re: A proper component tree
« Reply #4 on: April 06, 2010, 03:26:27 pm »
This should be a necessity....

Offline timb

Re: A proper component tree
« Reply #5 on: April 06, 2010, 03:59:07 pm »
It might be nice if we could move selected parts into layers.  If you move a part into a specific layer, it will take on the material of that layer.  Or at least some way of identifying all parts that have the same materials.

Offline solodesign

Re: A proper component tree
« Reply #6 on: April 09, 2010, 07:45:45 am »
I completely agree with this idea.
Screen pointing is too empiric.

+

Offline Richman

Re: A proper component tree
« Reply #7 on: April 10, 2010, 12:23:15 pm »
+1

Offline Pedro_Julio

Re: A proper component tree
« Reply #8 on: April 13, 2010, 11:15:34 am »
I got to see a preview of the soon-to-be-released Keyshot 2.0 this weekend and it's got the component tree.  There is a tab that allows you to toggle individual parts on and off.

So much other stuff too.  Such as the ability to place multiple decals on a single surface and manipulate them independently.   Love it.

Offline Jeff Hayden

Re: A proper component tree
« Reply #9 on: April 19, 2010, 10:33:43 pm »
The layer tree is in V2.0 and I have been doing demos with it for two weeks at the IDSA conferences. It is getting great reviews as it has been on many of our users wish lists for quite some time. All I can say is that it will be available soon and it will be worth the wait.

Jeff Hayden

Offline Speedster

Re: A proper component tree
« Reply #10 on: April 24, 2010, 04:28:57 pm »
Hi Jeff and all-

I've been mulling over the Component Tree.  Great and VERY useful tool!  But- it really must link somehow to the CAD tree, for a simple reason.  If you have a "part", it's just a part that KS recognizes as such.  It does not have to be mapped in CAD to work in KS.  However, in actual practice, I believe KS really recognizes "surfaces". 

Here's the issue: In almost every case I have a part, to which I have mapped different colors to different surfaces, to prep it for later material application.  So, a Component Tree that recognizes only the CAD tree components, although helpful, would likely cause problems if you only want to hide a single surface, like the "front" to access the "back".  Perhaps there could be an option for this situation?

Hope this makes sense!

Bill G

Offline J.B.

Re: A proper component tree
« Reply #11 on: April 26, 2010, 08:11:37 am »
Plus, keep in mind, not all of us use parametric modeling software and therefore do not have a "tree".
We still may have an assembly structure of different parts, but only if we choose to build it that way, with linked parts. Most of the time, I just use seperate layers.

In my experience, If I change the face of a solid to a different color, Keyshot will only recognize it as a seperate "face" and duplicate it on top of the existing solid. Therefore I now would have the face on top of another face and the first one would still have the same material as the rest of the solid while the individual face could have a seperate material applied to it. But it would be no good to have two materials on top of each other like that.
So what I am forced to do is actually seperate the face from the solid in my modeling program (in a sense, break it apart.) In order to get a single seperate face to apply a different material to than the rest of the solid. Not something I ever like to do, but no other way to accomplish this.

guest84672

  • Guest
Re: A proper component tree
« Reply #12 on: April 26, 2010, 01:19:16 pm »
What modeling program are you using, J.B.?

Offline J.B.

Re: A proper component tree
« Reply #13 on: April 26, 2010, 05:47:22 pm »
I'm using Keycreator.

guest84672

  • Guest
Re: A proper component tree
« Reply #14 on: April 26, 2010, 10:37:58 pm »
The "duplication" sounds a bit strange - no other CAD tool does this. I will have John Reis comment on it.

Thomas