Posts made by Jaycephus

I'm a millimeter away from switching from SU to Modo. It isn't as easy to just pick up and use at first, but as I learn it, I'm starting to think that, inferencing engine aside, I can be ultimately faster in Modo (for what I actually do, not just extruding blocks) than I can even approach in SU. Modo 401 now imports SolidWorks. (Huge for my situation.) Modo can do a full-screen preview render using Global Illumination with environment in seconds, sometimes actually as fast or FASTER than SU can update the same scene with SU shadows and profile lines in the actual scenes I'm doing. Modo won't choke on mere thousands or tens of thousands of polygons. Modo 401 can be had for $895 at some resellers, compared to the $795 we paid for a network license of SU. Modo does instancing and 'replicating', which means it can get into the millions of polygons compared to thousands in SU. I'm not saying it is better than SU in every way for ArchViz, but for my needs, it IS far superior. On the other hand, a lot of people are doing ArchViz in Modo now. Of course, both apps use polygons and can use .obj, so using both together is a great option.

@kevsterman said:

@shamos said:

i found a good and very simple interim solution
im using the windows explorer. i choose thumbnails and just drag&drop the components into the sketchup window.
works for me just fine

a.t.

I'd love to be able to do that but I can't see a preview image in my thumbnails which is really annoying

I had that problem on Vista Ultimate 64. If you open Explorer and go to Tools, Folder Options, View Tab, there should be a setting for turning on image previewing. Unlike XP, Vista doesn't have a 'Thumbnail' view. You just set the size of the icons, and they will be the image preview, if you have the correct option turned on.

How about a 7.1 release before the end of the year that fixes all the obvious bugs?

I just read this thread and I have to say that I agree with DacaD and kwistenbiebel the most.

But I also believe that the Warehouse should be massaged into something more like 3DContentCentral for SolidWorks, which isn't about advertising... It's about Design, and not wasting Time redrawing the wheel. 3DContentCentral has user contributions as well as corporate models, but it is all there for making the designer's job easier and faster, not for generating advertising revenue for SolidWorks' parent company.

Much of this thread tried to address the profitability of SU, and seemed to be mixing up the for-free product model metaphor with the standard for-profit product model. BUT I'M PAYING GOOD MONEY FOR SKETCHUP! For all the money I've paid, I expect it to handle AT LEAST as many polys or entities as $180 subdivision modelers. How about ZBrush? For the same money as Sketchup it uses multicore processing to great effect, realtime shadows, a full 4GB of RAM even though it isn't 64-bit yet, and easily handles well over ten-million polys without sweating, billions with some craftiness. Can SU even load and function with a model that requires 100 measly MB of RAM? In ZBrush (poly with subdivision smoothing and realtime self-shadowing) or Solidworks (b-spline with poly realtime rendering, including shadows and other shader effects such as ambient occlusion), I can basically have models so complex that all available RAM is used up, but the programs are still responsive!

If Google is expecting people to pay $500 to $800 for SU, then they need to make something that provides increases in productivity, plain and simple. That's how to be profitable! That's why I got SU Pro 5 in the first place. Solidworks '07 was SLOW to do factory automation layouts, but as Solidworks has increased their UI interaction speed, workflow speed, and operations speed, and 3DContentCentral has grown into something Google Warehouse wishes to be SOME day, the benefits of SU are slipping away. Yeah SU's still cheaper. Is it still faster? For some limited things, maybe, but its debatable. If I try to add Warehouse or converted CAD models, SU quickly becomes a narcoleptic turtle on morphine. But expectations are increasing. Blocky, flat-shaded models aren't acceptable anymore. Simple shadows are old-school, and it's becoming increasingly hard to claim they're 'real-time' shadows anymore.

I noticed that Google turned the once-very-nice SketchUp website into what amounts to just another Google Beta Software page. Since Google themselves have obviously confused THEMSELVES on whether SU is being developed under a free-product model or a for-profit model, and they may in fact view it as a "blurry object on the horizon", maybe I should just hook me up a morphine drip and learn to live at SketchUp speed.

@solo said:

They never had it as an option on the survey, only options were things that they might be able to fix, High poly support is a taboo topic to the GSU team as they have never mentioned it, aknowledged it or even responded to all the complaints and cries about it.

SU's shelf life is nearing the end without it, start learning another app now before you find yourself redundant.

Yep, and 'high poly' is a moving target that is now in the Giga-poly range in terms of how many polys some apps can handle at once. And that's Giga-POLY, folks, not Giga-entity.

SU is getting to the point that it can choke on 'LOW-poly', nevermind 'HIGH-poly', compared to what other apps and game-engines are now handling!

How's that 'free' working out for you now?

The original realtime features were meant for realtime assistance in visualization during presentation or during modeling. I remember the @Last marketing videos where they talked about this. Google really hasn't developed anything new in the graphics since they acquired SU, and it's embarrasing now how few polygons it takes to turn shadows into a non-realtime feature, at least in relation to where other modelers with shading or shadows are now at.

Personally, I would like to see the current rendering features made much more efficient. Surely using four 64-bit hyperthreaded cores ought to make shadows, textures and outlines much, much faster. REALTIME, even.

And in the spirit of just staying up with the current capabilities of other MODELERS, and the visualization abilities they have added, I would like to see a real-time or at least a non-realtime (but fast) ambient occlusion render. This combined with texture and shadow should make a very nice, easily visualized presentation or model. Or even without shadow and texture: It's amazing how much AO does for correctly perceiving the volume and shape, or relative depth of surfaces in the render.

If there is AO rendering with SU, then I can see a feature like an 'AO Texturizer'. I'm thinking of something where a highly detailed model (house with all moulding, mullions, etc. modeled) rendered in AO, and then textures of each side of the house are applied to a simplified model so that the medium detail is shown as a texure on the low-poly house. Or conversely, the poly-model isn't changed, but the textures are applied so that the model now appears to be rendered with AO in a realtime renderer that doesn't have AO at all. Having SU bake in the AO shading into a textured surface, or automatically making a non-textured surface a textured surface and baking in the AO shading would be pretty desirable.

It's a trick used in games all the time for both characters and mechanical devices:

• Model the large, medium, and fine detail.
• Render this with AO+texture in the modeler and get screen shots from all sides.
• Retexture the model using the AO+texture screenshots as the model textures.
• Remove all the fine (& sometimes medium) detail that can just be represented as texture only. (some fine details can be realized as normal or displacement maps in games - unlikely to ever be added to SU.)
• Now when rendered in the game, the object looks like it is being rendered with AO, but it's not.

The same trick can be used purely within SU to get better looking, faster-running realtime presentations, such as in walkthroughs/flythroughs of large developments or in the SketchyPhysics sims Wacov is doing. You couldn't tell the difference between realtime AO and AO textures unless objects move within the scene relative to the ground or each other, or they change shape, and even with motion, I think it's still over 90% as good as realtime AO.

@fossa said:

Is it just me or is the lack of a back button on the components window really unhandy.

It's officially not just you. Six months of no Back button.

I think they sacrificed it to the god of the vertex for more polygon handling speed.

Proof that programming by means of ritual sacrifice does not work...

well, except when the sacrifice is your own life, your wife, your family, your health...

Anyway, the spirit of the original @Last guys is now truly gone, IMO.

Thanks for the info, guys.

I found that at cheapest it was about $37 vs. $49 online wired vs. 30' wireless, Windows compatible, shipping included. (Microsoft brand)

With setting up keyboard shortcuts to control things, it sounds like two different vehicles could be controlled separately. Can xpadder be used to allow two different controllers to control one vehicle each by mapping the appropriate shortcuts?

Thanks Physicsguy,

Q: wouldn't the wireless types just have a usb transceiver that still works the same way as far as the PC can tell? I have a PC with 21" monitor and a X-Large flatscreen monitor nearby used as our 'TV'. (I have Netflix and an HDTV receiver, so we get all the local stations in HDTV, and watch recorded HDTV or Netflix streaming within the Vista Ultimate Media Center, or DVDs, listen to Pandora, etc. from our computer. We currently don't use a VHS, DVD player, or any of our audio-video equipment. Just the PC.) It would be nice to be able to sit in front of the 'TV' and 'play' SP!

Well, I don't think anyone simulates with a realistic number of molecules. The least realistic fluid animations use a particle emitter, where the particles use a 'blobby' algorithm to simulate a fluid surface. A single particle looks like a polygon-sphere, a droplet. A tight line of particles looks almost like a true fluid stream. The major downfall is that the particles don't have any expression of 'surface tension' or volume, so they freely scatter and also can flow to a single small spot. Scriptable particles have partially overcome even that drawback, if you can script in a kind of attraction that has a min. standoff distance, and still incorporates friction between objects, damping, and so on.

True fluid simulators that do all the work internally still operate on a mesh that you produce which has a relatively small number of vertices. Just like Finite Element Analysis (FEA) used to simulate the failure of a given part design that uses a given material, such as acrylic plastic or a certain aluminum alloy. The part model, usually created in software like Solidworks, is broken up into elements, small blocks, so that the part looks like it is made of tiles, like the space shuttle. (It also has a resemblance to a quad-only polygonal model where all the quads are the same square area.) But the tiles are blocks, and the entire solid has been 'blockified'. Then the expected 'force' is applied to the part in a specified vector, and based on the material selected, an analysis is performed and a report is produced that details the amount of force that produces deflection and ultimately failure of the part. Usually an image is generated that shows which areas of the part are stressed the most, allowing the designer to rework it to improve his design.

The point is that these sims usually work on mere hundreds of elements, maybe several thousand at the most, not tens of thousands, and certainly not millions. You might be able to make something that looks like flowing sand or wheat, or maybe even 'like' a fluid, if some more advanced physics scripting is added. But since SU doesn't do any special rendering, the best is could probably look like is 'watery particles'.

Is a 360 controller just a USB device, so you could plug it into a Vista PC, use xpadder, and immediately be controlling SP?

Are you using a single-polygon component? If you set it to always face camera, will it always face camera during a sim?

I haven't even gotten to looking at scripting yet, but it looks like the 'name' field is a string, so with a bit of extra code you could look at the prefix of the name as a class identifier, right?

so fire at all objects named: "enemy<something>"

or act on all objects named: "box<number>", but ignore anything else

It's my understanding that the underlying engine in SolidWorks has been Mental Ray (for about a decade), yet the implementation of the interface in SolidWorks is so bad to this very day that it is easily worth paying up to $1K for a plug-in renderer like Hypershot, VRay, or one of the newer commercial offerings, if you are doing commercial work where time is money, and quality cannot be compromised. I've also used Mental Ray in XSI, and the complexity is pretty high, and necessarily so due to the need to enable features used for moving, deformable objects in an animation, special effects used primarily in movies, and so on. The power is there, but the ease of use wasn't, as of a year or two ago. My personal preference is something like Podium or Hypershot that does much of the work for you, taking away confusing options in the process, while still enabling renders as good as, or likely better than you could obtain in Solidworks' MR-based renderer (PhotoDoesn'tWorks) after hours and hours of PAIN.

Yeah, as noted already, I'm sure they left off Max because no one would use the native renderer for product design renders, especially when it ships with MR included.

How does it fire with the keyboard?

Bob, that is an extremely good SketchUp assembly, and a very nice job. Personally, If I have access to SolidWorks, there is no way I would do that particular job in SketchUp. There is enough mechanical detail and repetition that the advantages of SW trump any advantages that SU has, and I believe you would be faster, with much better drawing output, in SW. Just having to keep in mind how many edges I need to use for a given cylinder or hole would be bad enough. But the three lobes could be treated as a pattern, and you would only have to work on one of them. The other two would update automatically. The history-based feature concept really takes the win here. As you build up the assembly in SW, you can have one piece rely on the shape/dimensions of another piece to drive it's own shape/dimensions. This makes the assembly 'smart' (well, as smart as the designer who has to build the 'intelligence' into the design, of course), meaning that making a change to a critical part would ripple changes through the design automatically (and any drawings already created would also automatically update, though they would still require tweaking at minimum). And you needed to make a mold as well! SW has built-in tools for that, though I've never used them. Given that the mold was built instead of machined, you probably would just use the standard tools in SW, not their mold tools.

Of course, SU PRO is almost as little as a tenth of the price of SW, so that can be a factor, but when you use multiple seats of SW year-round, and try to do your projects with as few engineers as possible, then doubling employee productivity is far more important than saving a few thousand up front. Of course, it all depends on what you're doing. As I stated previously in this thread, I believe SketchUp is a better tool than SolidWorks to do initial layouts and proposals (just like them fancy-schmancy architects ).

At least with the new Component features in SU 7, there are probably more cases where mechanical design can be done in SU as quickly as SW, at least until the drawing stage. But performance in SU 7 has really degraded on my systems.

The biggest request I have would be SPEED. SU has concentrated from the beginning on UI speed, which is an area where SW and PRO/E and most others have really suffered. Now SU needs to bring their polygon-handling speed and capacity up to the level of other polygonal modelers, which is an area where SU seems to have gone backwards. A 400K-entity model should not bring a 64-bit hyperthreaded, 4-core i7 CPU, dual-GPU, 6GB RAM system to it's knees. And that's with just basic hidden-line rendering. SU needs to step up with speedier real-time rendering of their current NPR features. It's gotten to the point where their real-time NPR needs to be treated as non-realtime, only turning it on at the end of the project. Third-parties have provided some pretty good stuff along the lines of quick photo-realism and realtime rendering, but it would be nice if SU had it's own native ambient occlusion real-time renderer.

And yes, I learned long ago about every possible trick (components, layer-switching, etc.) to allow me to pack more entities into a project. But I've opened old projects in SU7 that I created originally in SU 5 and 6, and they seem to be far more sluggish now. Could be faulty perception. I would need to install SU 6 and 7 on the same system and try them one after another to verify it. But I AM certain that SU 7 has not gotten faster.

BTW, have you ever made a pure hole component? I'm not sure that such a component would give you the geometry-overhead savings of a normal component, but I have made a counter-bore hole/hex-head cap-screw component that 'cuts' into the surface (like a door or window, of course). I assume you could make a blind or through counter-sink or -bore hole as a component as well. Have you made one that is configurable using the features in SU 7?

It's nice to talk about SU from a mech designer perspective, so feel free to bring up any tips or issues here.

Bob,

For us, I would say it is speed, speed, speed. Solidworks 9 is a massive improvement, no doubt, on speed over older versions (including UI interaction speeed), but it is still cumbersome to make individual parts and assemble them up compared to working in SU. If you do it the fastest way possible, you end up with something that subsequent engineers will just throw away anyway because it isn't mated up properly, built with future modification in mind, or made with the particular manufacturers' models that they will end up using, and so on. Why waste time designing a robot end-effector in SW for a proposal when the final end-effector NEVER looks like the one in the original proposal. It's best to go for speed and appearance, and let the subsequent engineers worry about precise function. One exception would be if we are cutting payload ratings close, and need to know precisely what a realistic end-effector masses during the proposal stage. Then we would need to put in more design work, build it in SW, engineer in all the pneumatic cylinders, etc., so we can get a pretty accurate idea of the mass in order to select the cheapest/smallest robot that will do the job. (And then the client forgets to tell us that their whole product is made of stainless steel and weighs twice as much as they originally told us! )

And of course the pre-sales design is a moving target, as shown in the progression in my first post, so being able to blow away half the layout and quickly redo it, tweak positions on the fly in meetings, and so on, are all important.

I've done pure SolidWorks projects too, but this has been only because I needed inverse kinematics solving on a 6- and 7-axis industrial robot arms to verify reach and check interferences. I'm just getting into SketchyPhysics, so I may end up back in SU for that kind of thing as well. It may be that SU + SP >= SW, at least for quick studies, and then for the more precise cycle-time analysis robot studies, I would need to use the robot manufacturers' simulation software anyway (another layout that doesn't convert back into SW even if it started in SW).

And over the past couple of years, we've been continually pushing against the number of SW licenses we have, so getting a seat of SU at a tenth of the price of a seat of SW is a factor.

Hi Bob,

I've used the demo of RightHemisphere DeepExploration CAD Edition originally, but never bought it (who comes up with their names? Worst marketing decisions ever.)

It could open SW I think (or maybe just IGES, can't remember), and export 3DS originally, which imported into SU pretty well, with maybe just a bit of tweaking required every now and then. Now DE actually exports in the SU .skp format.

Now, I have a license of IronCAD which I use purely for its translation abilities from Nurbish formats to polygonal formats. I also have to take SW and SU models into other software such as various proprietary robot simulation programs.

I've never tried .sat from SW through AutoCAD into SU.

To Rich above:

The models in the layout above come from multiple sources. Some were made in Sketchup by me. The forklift and pallet-jack came from the Warehouse. At the point in time that the above layout revision was produced, some work had already been done in Solidworks, so some of the custom machinery in the room to the left is a simplified model of the equipment assembly in Solidworks, exported and converted to something that imported into SketchUp. At that time I think I was going from SW to 3DS to SU, but now there is a more direct solution. The earliest revisions of this layout used my own SketchUp models for our custom machinery. Some of those revisions used a SCARA robot at multiple positions. It might be interesting to post the earlier revisions to see the progression from first concepts to the above near-final layout.

The robot models are also from Solidworks, originally created by and downloaded from the robot manufacturer as Solidworks files. I never put the robots in the 3D Warehouse because I wasn't the creator, and I wasn't sure that the manufacturer would allow it. They are pretty touchy about their information and I might have had to agree to some legalese BS to originally download them. If I'd created them from scratch it would be a different story.

If I can find them already in the public domain or verify that they are not 'controlled', then I'm thinking I will joint them up in SketchyPhysics and upload them. Currently, they are merely grouped with some extra axes thrown in to make them a little easier to pose.

Here is the very first fast and dirty robot SU model I made for the very first SketchUp layout I did for a client called the United States Bureau of Printing and Engraving, otherwise known as the Greenback Factory.

And with the Hypershot demo, LOL:

@chris fullmer said:

That sounds like Cirque du soleil to me!

Not quite...

This page has some good info on it... scroll down to the second stop sign and look for descriptions of the tech used in the 'attraction'.

http://www.screamscape.com/html/disney_s_california_adventure.htm

I'm glad you asked.

The company I work for is called ARM Automation, located in Austin, Texas.

We do the design, integration, build, and programming of factory automation, such as the robotic manufacturing equipment shown above. (I personally also do controls design, and programming.) We use industrial robots, custom-designed robotic systems, machine vision, servo-motors, motion controllers, etc. with our own custom-designed equipment to provide automation solutions to various kinds of manufacturers (or other kinds of companies). We're currently finishing the system shown above, and we're also producing some custom multi-axis underwater positioning systems for use by an international entertainment company.

We've done a lot of work for a certain local major computer manufacturer, a major chip manufacturer (the edible kind), and various sorts of food, petroleum, medical, and goods manufacturers.

See http://www.armautomation.com