@tig said:

The importer v1.0 was made to import 'geometry files' only.
Images require you to pick a position and a scale - there is no 'automated way' of doing this via import - it must be by entities.add_image - I'll add this to the importer too...

Thanks, TIG for clever advice. I did this to import a local file, and it worked:

objEntities=Sketchup.active_model.entities
point = Geom::Point3d.new 10,20,30
objEntities.add_image "c:/temp/ypykka800.jpg", point, 300, 300

The user interface File > Import... > file open dialog would accept a URL as a file reference. Is there a way of doing that in a SU Ruby script or do I have to get the file first into a local directory?

BTW I didn't spot entities.add_image as I don't have a way browsing the reference material. Is there a reference manual in PDF which would be a bit easier to delve into than the online HTML pages?

@tig said:

Here it is:

import_from_folder.rb

...

v1.0 20091124 First issue.
[attachment=0:2cg8uxas]<!-- ia0 -->import_from_folder.rb<!-- ia0 -->[/attachment:2cg8uxas]

Hi. I copied a couple of png-files into a folder and tried out this demo. Yes, it imports a png, but not all of them.

I'm trying to get into SU ruby scripting, but there seems to be something wrong or missing in my installation or script.

Another symptom which could be of the same kind: If I issue a command 'status=Sketchup.active_model.import("c:\temp\test.png",false)' in the Ruby console window, the engine replies with a messagebox saying: 'Image file invalid!'

This must be something trivial, but is there someone around who could help me in taking the first steps into this new world.

@wo3dan said:

I'm able to place a (transparant) box on a corner of a building at position:
51.828187N / 4.706535E , checked by placing a (corrected) place mark!!!
Next I'm able to reposition that box on:
51.828188N / 4.706536E , checked again by placing a new (corrected) place mark!!!

Hi Wo3Dan and other fellow SU designers. In our environment we would need the same level of precision (5 or more decimals) and unfortunately the SU designers don't want to support our (and Google Earth's) needs. You seem to have been able to create a work-around, but unfortunately I cannot quite catch the idea. Can you give a more detailed account of the procedure that you use.

It seems to me that you are creating precisely aligned placemarks in Google Earth and that you import (Tools > Google Earth > Get Current View) them into SU to get better precision. Is that correct?

I still have a feeling that the easiest way to settle the problem would be that the SU designers would offer us the same level of precision that is being required in the Google 3D Warehouse - Acceptance Criteria. Correct alignment won't be achieved as long as rounding errors produce deviations of a magnitude around 5 meters (as they do in our area).

We ought to have a flexible way of entering custom locations in the most common coordinate formats. In my environment people are used to the <degrees> <minutes>.<decimals>' -format (and <degrees> <minutes>' <seconds>" also seems to be acceptable). That's the way how our national map service lets us define coordinates and that's how at least my GPS wants to present its measurements on the display.

Google Earth is very liberal as to the way how Lat/Lon coordinates are entered. <degrees>.<decimals> <degrees> <minutes>.<decimals>' <degrees> <minutes>' <seconds>" are flexibly converted to the format defined in the application options. So why aren't we offered the same flexibility in SU? Here <degrees> <minutes>.<decimals>' will convert into <degrees>.0000

While on the topic: The Set Custom Locations dialog is in a couple of ways a rather buggy creature. For instance: While entering values we tend to switch tasks back to the application where the Lat/Lon value is being read. That works fine, but task switching back to SU (Windows Alt+Tab) is difficult as the dialog seems to mask out the SU application from the Windows running tasks panel.

Sorry TIG if I couldn't follow your line of thought. I was thinking like this: Assume that the user is drawing with the line tool. That's certainly a situation where drawing axes (and inference colors) are needed. So then the user would like to have an idea of the coordinate system. Have a quick look at 'a-a', then bail out by pushing Es... Eek. Escape also interrupts rubberband drawing. - Just to state an example of a potential conflict. But thanks for your nice contribution that I tried to improve.

I tried Tim's elegant scripted solution. Was surprised to see how well it worked while orbiting and panning. But zooming was rather sticky. But that's not too bad because the axes don't change direction while zooming. Maybe you could tune the script to bypass your routine during zooming, Tim. Would that give a performance advantage?

This flexibility was for me a piece of additional proof that SU is a well designed program. I believe that if we can produce a usable scripted solution then it would be easier to achieve an accessibility update in next version.

Tim: Are you sure about using the Escape key to end 'accessible axes'? It is an accelerator for other things too. Or do you think that color-blind user would primarily toggle quickly into the 'a-a' mode and back to selection whenever they need to orient themselves in the coordinate system.

Thanks Jim for the nicely presented alternative suggestion.

Selecting pen style is as easy as changing color. The Windows API offers five alternatives - solid, dash, dot, dash-dot, dash-dot-dot. - Unfortunately the SU inference engine will also need a way of showing axis hints.

The only real pain is generated by the effort of adding yet another ('Accessibility') property page to the Preferences dialog.

Thanks for all the good advice.

To sum up some of the ideas proposed, it seems that a feature request of some kind of an 'accessibility' scheme could be an easy remedy: The user should be able to replace the colors of the axes with various grades of grey. This is actually in line with what the student proposed himself. He said that he can see those differences in brightness, but it would be easier for him if the differences would be a bit more marked.

One doesn't have to be programmer to know that implementing this kind of an idea is a trivial program development task. So as proposed: If no one comes up with a better idea we'll have to make a SU8 feature request.

Hi. I've just had the first session with a group of local sketchup students.

The 'drawing axes' is one of the first things to speak about in introducing new people into SU concepts. So I told about the red, green and blues axes. The short demo was followed by the students' hands-on activity, where they were familiarizing themselves with the newly learned idea of drawing axes. - After a while one of the students told us that he was color-blind and that he had difficulty in handling the color system. He could see that the three axes differed in brightness, but it was rather hard for him to distinguish them from one another.

As color-blindness is a rather common problem, this is probably a FAQ. So, dear fellow community members: Be so kind and indicate where we can find ways of tackling this issue. Thanks.

Philip