No rush but would be interested whether it is still in hand; let us know if there are problems you need help with.

For easing in and out see this demo. Select type and click. Mental workers can visit here.

On second thoughts, perhaps you should model them as you would build them, course by course, cutting one or two to complete each ring while maintaining joint overlays. I haven't tried it myself, but I can see it will be quite tricky. Have fun!

Make sure every scene is updated with the style you want. Set the style variables in each style edit section. I think that should help to solve your problem.

Suggest you change the title to "Help with brick dome" and put "brick dome" in the search box to find other topics and solutions. Don't forget the wedges are both for the vertical and horizontal curvatures. But you could try cutting one brick to shape then radial copy it vertically; then radial copy that array horizontally.

Thanks Gaieus for remembering my work. Unfortunately I got a bit disillusioned with trying to make the new version of the machine compatible with Macs, but now I have picked myself up and restarted making a new version from scratch (step by step method). These machines will enable their owners to build hierarchies of scenes (what I understand this thread is about) as well as collections of components (to allow them to appear in many different scenes without layer and outliner complications and restrictions).

Thanks Ketchup for asking the question I also wanted to ask and thanks TIG for answering it.

One thing I found is that with the standard cherry wood texture and a small cabinet the coloured handles are not visible until you zoom out quite a lot. Zoom extents doesn't seem to recognise texture sizes. Is there something I have missed to make it simpler?

Thanks.

wdbao, I hope you don't mind my moving our PM discussion here. It just might be of interest to others.

In a PM to me
@wdbao said:

... i hope i can contribute sth to this nice community
but i haven't had much time, most of the time i have to work day and night
believe me ...

Living in Hong Kong and China for many years I certainly believe you!

So I am wondering, in pursuit of the point behind the question in the title, whether you would be better off for the time being just acknowledging that Ruby code can assemble components as a 3D model and concentrate on exploring how to structure data of one of your current projects that will later enable you to so. The same data can be used for buying materials, planning and monitoring progress, instructing labour, supporting payment requests and so on. So you should be able to incorporate your research into your day to day work for the benefit of your business.

As I mentioned in one of my PMs I was responsible for fitting out the Forum Hotel in Shenzhen, China - 750 guestrooms and three floors of public spaces - where I put to the test my previous adventures into using spreadsheets for large quantities of data (particularly on Norman Foster's Hong Kong Bank project). This was in 1988 about a year after Lotus introduced their multi-sheet application (123 v 4.0), which initially I thought would greatly help deal with the three dimensional nature of data. But it didn't; let me explain using a simple example of a concrete column by looking at the hierarchies within the data.

COLUMN > Width, depth, height, x, y, z;
COLUMN > Material, labour, equipment;
COLUMN > Start date, duration
COLUMN - Material > Concrete, rebar, plywood, struts, clamps;
COLUMN - Labour > Steel fixer, carpenter, concretor;

Of course this is just the start (yet to list are suppliers, costs, prices, instances of other columns and on and on). It is like you need to keep turning each list through 90 degs alternatively on the XY, XZ and YZ planes; it just doesn't work; either the data overlays other data on the XY plane or is just too difficult to drill down into the underlying sheets in the Z oriented planes.

What we did on the Forum Hotel was to list everything in one column only adding data to columns to the right to terminate a hierarchy - e.g. width = 300mm. We set up a number of columns on the left of the data for various indexes to allow us to alternatively sort the data into different aspects of the object in question. One aspect was shop drawings (drawn by hand in those days) which now could be the natural output of structured data as a fully supported Sketchup model. And of course all that tedious sorting can now be avoided by animation.

What I realised from our discussion so far was that the menu system I was using for namesets wasn't in line with what I have said. So I have now started to redevelop it. I think the structure is OK for the objects in the nameset itself; it's the backup that assumes devices rather devices being called by the data (or something like that!).

Anyway I think if you would like to start to introduce some of what I have said into your day to day work, hopefully quite soon I can take your data and turn it into a nameset ... and then we can use it to start generating Sketchup models. This should then help you learn Ruby coding.

Also for the Ruby part see Automatic Sketchup which is reviewed in this topic.

Well even for a graduate that was a fine post in English. Actually I met some other Chinese graduates the other night (one came from Foshan btw) who also enjoyed trying out their ideas in English - made me feel very bad only knowing a few words in Cantonese and only two or three in Putonghua. But my main concern is while English is an international language of business, JavaScript is not.

What this means is that many are coming up with simple solutions like "drawing a whole building structure with code" without considering how this links in with other persons' simple solutions. The outcome is an unnecessary complexity of simple solutions. My interest is in finding a way to unite the efforts of all so that the complexity is handled by the computer, with only the required information being presented for the task at hand; this means automation.

My purpose in sending you the current development of namesets was mainly to demonstrate that we can make machines from HTML and JavaScript - compare banks making ATMs to substitute cheques and cashiers. Of course ATMs only deal with money whereas most of us have to deal with a diverse range of objects and their attributes and properties. This is why structuring the information as hierarchies of objects with key/value records is important both for navigation and automation, and I am afraid adding columns in spreadsheets just doesn't come close.

One benefit of such machines is capturing information as close as possible to its source. There need never be ridiculous situations where a designer determines a dimension for a column, draws it in plan and section, sends the drawings to a builder who extracts the information to instruct the setter out. Instead the dimension immediately gets stuck to the column for all to see in whatever format they want to see it. The only change in workflow is omission of duplication. I hope you will like to think about that.

Very good ... btw I am sure you have come across these.

A simple image to hopefully explain "while presented in 2D it actually represents 3D"

Of course animation is needed to allow columns to open in a 2D space.

Might it be you did not update the style after changing to X-ray?

edit: no tried without update; preview is OK ... but it might be something like that

Just a few points you might like to consider.

Objects are used in JavaScript rather than classes but hierarchies of both are important. So are the hierarchies of whatever you are trying to model. For example, does a wall belong to a room or to a floor? It also could belong to a concrete mix or a structure subcontract; a time period or a submission ... To make your data useful it needs to accept multiple links.

To achieve this in spreadsheets is just too difficult. While in 1989 they became three dimensional with multiple sheets, they never really satisfactorily harboured 3d data. The solution I found was to simply lay down column and row headings side by side in columns. Each column has its own axis; while presented in 2D it actually represents 3D. A column of floor numbers is like a section, an adjacent column of room names like a plan. These columns move so that you can navigate to and manipulate large amounts of data and create as many links and cross links as you need.

Data in spreadsheets can easily be converted into delimited plain text. If you have many you can create a macro to automate it somewhat. What I mean is that because data is in a spreadsheet don't assume the solution is limited to it. Really plain text is king because it is common to all proprietary and open source applications ... and humans!

Input can always be done by non-professionals.

I would suggest you think about a web based application with a Ruby file to work Sketchup.

Here's the latest reply which I can just about understand.

@unknownuser said:

Unfortunately Sketchup API is hidden in compiled C library thus RubyMine doesn't understand it. RubyMine is able to parse only libraries written in Ruby + standard C-based Ruby interpreter core libraries. Please submit an issue at http://youtrack.jetbrains.net/issues/RUBY. It is possible to create/generate ruby stubs for Scetchup (similar which RubyMine uses internally for codeinsight related to Ruby core libraries) and it isn't too hard. At current moment this is a low priority issue and only a few users asked us to implement it.

I am not sure I am the right person to submit an issue. Please let me know if you are willing to take it on.

I asked the same question in the RubyMine Forum.

I have just started to use this IDE for the nameset web dialog code. I am far from a seasoned coder so if anyone is familiar with RubyMine I would be grateful for some guidance. For example, after inspecting the project I get these warnings:

It seems I need to do something to get RM to acknowledge the SU Ruby API? Is that right? And if so how?

Thanks

I agree. I am a "reluctant" coder so I found this book's straightforward approach very refreshing. It is particularly useful for those few of us who see automating Sketchup as a new basis for communication generally.

@chris fullmer said:

+1 Thom - Martin you lose me (and my interest) every time you rant about 30 year old grudges. Just ask a question with relevant info only and leave MSFT (whatever that is) out of it, pretty please?

Try seriously working through a small part of Uncle Holly's tutorial, it's full of that kind of stuff. Intended to impress (e.g. MSFT is Microsoft's Nasdaq ref), actually it quickly becomes irritating beyond words. Purged of such "style" I believe Martin may have something useful to say.

@leedeetee said:

@chrisglasier said:

think about what would suit following activities not just about submitting the fee account for a beautiful set of documents.

I can assure you I wasn't thinking about that, seeing as though I don't really know what you're talking about!

Sorry my comment was not really directed at you but the whole concept of "deliverables" a newish term differing only in name from those in the time-honoured RIBA Plan of Work. I seem to remember stage D was named Working Drawings. It made reference to plans, sections, elevations, details and schedules.

It was quite proper to issue a fee note when these were completed to the professional standard. The anecdote I mentioned before about a sanitary ware schedule happened about twenty-five years ago. So perhaps you can understand my despair at reading your note and can forgive my rather brusque repost.

The biggest opportunity now is to figure out how to capture the ability to pass on reusable linked up information, and I think you will agree in this we are sorely lacking.