KeyShot Forum

Other => Wish List => Topic started by: quigley on February 17, 2010, 03:26:23 AM

Title: A proper component tree
Post by: quigley 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.
Title: Re: A proper component tree
Post by: Pedro_Julio 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.
Title: Re: A proper component tree
Post by: Tim 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.
Title: Re: A proper component tree
Post by: jbeau 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
Title: Re: A proper component tree
Post by: timb on April 06, 2010, 03:26:27 PM
This should be a necessity....
Title: Re: A proper component tree
Post by: timb 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.
Title: Re: A proper component tree
Post by: solodesign on April 09, 2010, 07:45:45 AM
I completely agree with this idea.
Screen pointing is too empiric.

+
Title: Re: A proper component tree
Post by: Richman on April 10, 2010, 12:23:15 PM
+1
Title: Re: A proper component tree
Post by: Pedro_Julio 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.
Title: Re: A proper component tree
Post by: Jeff Hayden 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
Title: Re: A proper component tree
Post by: Speedster 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
Title: Re: A proper component tree
Post by: J.B. 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.
Title: Re: A proper component tree
Post by: guest84672 on April 26, 2010, 01:19:16 PM
What modeling program are you using, J.B.?
Title: Re: A proper component tree
Post by: J.B. on April 26, 2010, 05:47:22 PM
I'm using Keycreator.
Title: Re: A proper component tree
Post by: guest84672 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
Title: Re: A proper component tree
Post by: jreis on April 27, 2010, 06:03:51 AM
The duplication happens because the face still has the original material properties of the solid even though the face has a different color. Basically the face has 2 materials properties, one of the face and one of the solid. I’ll talk to our developers to see if that can be changed for the OBJ export.

Myself, I always create a copy of the model file for rendering. I’ve done this with every CAD and rendering software I’ve used. This way I can breakup the CAD model as needed for rendering and I don’t disturb the original CAD model.
Title: Re: A proper component tree
Post by: J.B. on April 27, 2010, 07:29:34 AM
Hi John,

Thanks for the input. Yes I could make duplicate files for rendering and in most cases it will probably not be a big deal. But some of my files get in to the 200 to 300 + megabyte range. If I start duplicating all those it will start to starve me of my drive space quicker than I might like. But definitely an option for the smaller files.