Is there any way to convert multiple welded lines (contours for example) to segmented lines with set segment lengths? I have used Bezier Spline in the past to get better "From Contour" results by converting contour lines one at a time to lines made with consistent segment lengths. This works considerably better than the "simplify contours" plugin that still creates snow drifts all over the place.

EDIT, kinda related... here is a video I created showing how to use the Polyfit LISP (from polyface.de) in Autocad to ultimately get a more efficient model to do a From Contour in SketchUp.

http://youtu.be/6bQtJhDn_lc?t=3m40s
(Easier to see in HD directly on Youtube, also jump to the 3:40 mark to see the polyfit part.)

I've done a similar thing using BezierSpline with the Polyline Divider option, but I need to weld and apply the tool to each contour line rather than all at once with the Polyfit LISP.

-- matt

Hey all.

I know there are functionally similar type questions here and here. But I am going to ask anyway...

Does any plugin exist or would it be feasible to have one written that would automatically make any output from the "3d text" tool to have edges hidden? I know how to do this on a per-group basis, but I really need it to be automatic and exclusive to the component created from the tool. I don't actually create 3d text, I am primarily using it for some quick space planning documents.

-- mc

@danyhkim said:

Is there any possibility of a protein structural renderer that would calculate sheets and helices, kind of like RasMol does?

Aerilius, I am probably asking the same thing as DanYHKim, but is it possible to model the pink and yellow things in the attached graphic? I downloaded the .pdb file from rcsb.org, and then exported the file to MOL v3000. That worked fine to model the molecular structure... which I am guessing is by design, but I am trying to find a way to simply model the other stuff.

I have been battling this issue for over a year. It is frustrating as F.

Anyone get a chance to try the new Apple mouse with SketchUp? I am wondering how/if the middle "button" works.

I have had images show up as all black in other applications if they are saved as CMYK.

I think my problem is related to this discussion.

I have three children items and I would like only one to be shown at a time. I thought I could do this:

Parent
randthing=randbetween(1,3)

Child1
hidden=if(parent!randthing=1,0,1)
Child2
hidden=if(parent!randthing=2,0,1)
Child3
hidden=if(parent!randthing=3,0,1)

But it looks as if each child refires its own value for randthing, making the hidden value not mutually exclusive as I would like.

I could have sworn that I successfully did this before. Not sure if there was a hack or not, but if anyone has any ideas it would be appreciated.

I am getting some crazy ideas to concatenate a string and the random value and then stripping out the value once again... just to keep it from changing.

FRUSTRATION EDIT

I thought I could outsmart the problem by doing this:

Parent
randthing=randbetween(1,3)
randhack="x"&randthing

Child1
hidden=if(parent!randthing="x1",0,1)
Child2
hidden=if(parent!randthing="x2",0,1)
Child3
hidden=if(parent!randthing="x3",0,1)

But that failed too. It looks like the randbetween() function gets re-fired no matter how far back or indirectly it is linked. Cripes.

I found out from the source that the issue is by design. It has to do for when there are imperial and metric components mixed together under one parent shell. It had to be one or the other, and imperial won.

So to answer my question and anyone else who stumbles across this...

If your DC is in metric and you want to use this common trick to snap to increments

=largest(100,round(current("LenX")/100)*100)

You will need to apply an "inch to cm" multiplier of 2.54 to the current() function to avoid general screwiness when scaling.

=largest(100,round((current("LenX")*2.54)/100)*100)

@chris fullmer said:

Did you set the DC itself to metric by clicking on the ruler icon?

Hi Chris, yeah did that. I thought the issue might have had something do do with starting with inches and then switching over or possibly having some other nested piece that was in inches... but ruled those out as well by starting from scratch with all the metric in place. If any Googlers are reading this, I tested this in 7.0.10248 for Mac and 10247 on PC.

I am moderately versed in DC authoring, but I am trying some authoring in metric for the first time and am having issues.

I think I have narrowed the problem down to a current() function. First off, I have my default units set to metric (which starts the Comp. Attributes in cm) I have my LenX snapping to increments of 100 (cm) with this formula:

=largest(100,round(current("LenX")/100)*100)

The largest function is being used to keep the value from hitting zero and causing other issues.

With this function, I was getting unexpected results when scaling. I created a custom attribute called "currenttest" and set this in its field:

=current("LenX")

Surprisingly, when the formula in LenX resulted in a value like 100, the value for currenttest would equal the inch equivalent, which in this case is 39.37. If that is the case I can see why my scaling is getting erratic.

So my questions are: Is this a bug isolated to the current() function? Do all functions result in inch equivalent? I'll do some testing on that myself. And finally, has anyone else had issues authoring DCs in metric?

For the time being, I guess I will just add a cm multiplier to apply to the current() function and any others I happen to have metric/imperial issues with.

Matt

@jim said:

I wrote a ruby function to get the date in a DC.

For that to work on DC, does it need to be installed on each machine that uses the DC, or does it somehow embed the information in a distributable DC?

Hey Chris, I had a feeling that you would reply.

As for the Alt/Azm pairs... I think they would repeat at different places, but I also think that a pair at a specific location would be unique to an exact date/time.

It dawned on me today that there might be a way to determine the date and time for use in Dynamic Component formulas... for instance if you wanted foliage color to change or completely disappear based on the season.

There are a handful of online calculators, such as http://aa.usno.navy.mil/data/docs/AltAz.php, that will determine azimuth and altitude based of date, time, latitude and longitude. Could not that formula be rearranged to determine a model's date and time based of the LAT(), LNG(), SUNELEVATION(), and SUNANGLE() functions?

Correct me if I am wrong, but are not the functions SUNELEVATION() and SUNANGLE() equal to altitude and azimuth?

-Matt

@shotster said:

Thanks for the info. They are interesting products, but they don't appear to do exactly what I need. Not only that, but I'm on a Mac, and they're Windows-only. Thanks though.

-Steve

Hi Steve,

You should look into iShowU. There is an option to record without recording the cursor. It's a little bit of a hack, but it works. I am using the $60 pro version, but I believe the $30 standard version has the same ability to not record the cursor.

Here is an example:

[flash=640,505:3qwjvdou]http://www.youtube.com/v/FoUdz3c5uU8&hl=en&fs=1[/flash:3qwjvdou]

I have had a similar experience to what is being posted. DC potential seemed big at one time (and I still think the potential is there) but they don't really fit into the "3D for Everyone" motto.

IMHO, here are the big issues with DCs:

1. They are good for many different specific things.
2. They need to be thoughtfully "authored" for those different specific things.
3. They need to communicate that they are for that specific thing.
4. They need to be easy to find and implement from the user end.

For example, take a solar panel. A DC solar panel could be built so a user can cycle through different models. Maybe the DC even shows various inverter and grounding wire placements.

A solar panel can also be authored to track the sun (but sadly not truely dynamically, needs be right-click-redrawn after the sun is adjusted).

A solar panel can also be built to glue to a surface and replicate/position when scaled.

An argument could be made that a good solar DC should include all of those points, but detail and replication do not gel. They need to be authored differently.

Additionally, for the sake of argument, say all solar panel DCs on the 3DWH fall into one of those categories, the user pretty much has to download each one and play with it to figure out what it does, and that even assumes that the DCs were correctly authored in the first place, which is extremely rare.

The short of it is that trying to find any component on the warehouse, not just DCs, is akin to finding a clean needle in a stack of dirty hypodermic needles.

If DCs are going to have any success, there needs to be a few things: Skilled component authors, a better find-and-download method, and finally a "dynamic" purpose which is appealing and broad enough to the user that the skilled component author has a reason to make the DC in the first place.

Right now the 3DWH is filled with green-badged DCs that are half or incorrectly built, have an unclear "dynamic" purpose, and generally are a buzzkill for anyone trying to find and use dynamic components in the first place.

Anyhow, this is going from observation to rant so I will end it at that.

I am a little late to this thread but thought I would chime in. At one time I was excited about the sun-tracking ability of DCs, but the buzzkill for me was that the DC would need to be refreshed with a right-click... it would not track the sun as the sun moved.

Matt

I have had issues draping things when they are in a group. Sometimes it helps to explode the group/component and then drape the geometries. Can you post the problem pieces in a skp?

For the second question:
Library -> Application Support -> Google SketchUp 7 -> SketchUp -> Materials

I don't quite understand the first question, can you reword or perhaps include a few screen shots to aid the description of the issue?

Cheers,
Matt

That is interesting. Could it be a result of some installed plugin misfiring?

Here is a Mac trick you can do to find out.

1. Navigate to your SketchUp directory which should be at /Library/Application Support/Google SketchUp 7/SketchUp

2. Using Spotlight built into the upper right of the finder window, search for the string "No entity data returned" complete with quotes and then after hitting enter, click on the "Contents" option.

... I just did it on mine and no plugins have that string but two .js files did.

configurator.js
manager.js

These are dynamic component things... Sorry, this has kind of turned into a rambling but I would put my money on the issue having something to do with DCs.

@gaieus said:

I could imagine a DC "stretching" in a certain direction then you could explode it and use drop.rb to get all the nested pieces onto the ground. Would that be "enough"? Note that it couldn't be modified afterwards so this is a final (and non reversible, destructive) way.

I think in this situation the drop.rb plugin could be used in a non destructive way. Instead of exploding the DC, it could just be edited by double-clicking on it. I threw together a test file and screen capture. Kevin, I would be curious if this would be a reasonable solution.

Scale the DC in the attached skp, then edit it, then apply the drop.rb plugin (also attached just in case you don't have it).

Sorry, forgot to record mouse cursor in screen capture.

[flash=720,405:10e8y6vn]http://www.youtube.com/v/cUAcXObu2mQ&fmt=22&hl=en&fs=1[/flash:10e8y6vn]

*edit
I should add that this only really works as long as the z attribute is not formula derived (black)

Regards,
Matt Chambers
concept3D

solartest.skp

drop.rb