SolidWorks livelinking issues

Started by quigley, August 30, 2016, 05:13:19 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

quigley

Not sure if this part of the forum is active or not but here goes.

We use keyshot with (mainly) SolidWorks 2016 and Rhino 5. 90% of the time we use the SolidWorks plug in to move from SolidWorks to Keyshot. 90% of the time it is a one way process. But the 10% when we need to go back and edit in SolidWorks then return to Keyshot, of that 10% probably 99% of the time we need to reimport from scratch as live linking does not work a lot of the time.

Our biggest issue is when working with configurations or when changing the visibility of parts in SolidWorks.

A typical scenario is this. We set up a configuration in SolidWorks with some parts hidden (in the configuration - we link display states to configs). We then export to Keyshot, set up a render, then realise we needed to show some parts. Switch back to SolidWorks, show the parts, update the config, live link back to Keyshot and....well...99% of the time what happens is ONLY the parts that have been unhidden in SolidWorks come through, everything else vanishes. So we close Keyshot and reimport the lot again from scratch.

Keyshot is its own worst enemy in this, being so quick and easy to use, we just say, what the hell, and reapply everything - usually only takes a minute or so. But if you have spend ages setting up labels and textures it is a real pain when this happens.

Another issue is that the plug in does not appear to handle labels applied in SolidWorks - it just ignores them (leaving you to set up labels in Keyshot, which is really not great - full explanation see textures forum thread)

Now for Keyshot this might not be important yet. but in coming months/years it will become important as SolidWorks Visualise actually starts to become more integrated. Currently Visualise is probably one of the worst pieces of software I have used in recent years, but that will get better, and the integration with SolidWorks will improve. So for v7 guys, can you give the SolidWorks linkages a kick please. No matter what the marketing teams of competitors suggest, SolidWorks is still the number 1 3D CAD app for product design, and will be for many years to come. I want to ensure Keyshot stays at number 1 for visualisation of SolidWorks files as well.

Robb63

Hi Quigley, I don't have any answers for you, but I am experiencing exactly the same thing with the Rhino Plug-in.
I also use SW, and Rhino but typically setup my renders in Rhino so I can move parts to named layers and apply material in KS that way

I started a thread about it a short while ago. No answers yet, but I sent Thomas some files that had the issue to look at. I agree with you though, that this is huge moving forward. I had grown to rely on this working and had changed my workflow because it was so helpful. Now I can't rely on it and have had to change my workflow again.

The thread for the Rhino issue is below...
https://www.keyshot.com/forum/index.php?topic=12897.msg63715#msg63715

guest84672

We will continue to look into it, but as far as your example goes Robb63 I was not able to reproduce this. Everything updated just fine. I will run some more tests today.

We will also look into the SW plugin issues.

guest84672

As far as labels and textures go, correct. We can't get that information through the API.

quigley

Now you mention it yes it happens in Rhino as well. What you do with Rhino is what we use it for as well - setting up more complex renders that we just can't be bothered to do the proper way with assembly mates etc in SolidWorks (and we have Rhino scenes all set up and ready to go for rendering certain product types).

As for the SolidWorks labels and textures thing, has this changed with recent SW versions? I am 90% sure we used to open up native SW files in Rhino and Modo that had textures in place. I'm probably wrong though!

guest84672

It has always been that way. At least for the plugin.

We will take another look at the direct importer.

We already identified an issue with the plugin when it comes to hiding and unhiding parts, so thanks for reporting that. We will check other plugins as well to make sure that everything is working as expected.