ETA on ShapeJS2 Cocreators?

I could just be looking in the wrong places... but is ShapeJS2 available outside the demo page at https://shapejs.shapeways.com/v2 ? I'm just itching to try a few things in an actual automated cocreator scenario.

Thx!
Tim Shay

I second THAT!
I'm excited to get my creators in my shop and for sale.

Well, in that case, @AlanHudson, I'd like to indicate that ShapeJS co-creators are absolutely my number one interest in the development of Shapeways - everything else is way, way behind.
As I'm sure you know already, but since you asked...

I like the idea of a regular progress report, because it's pretty frustrating not to know what's going on. I think twoshay at least will be with me on this.
I saw hunter_yaw make a similar commitment about orientation. Is this a new policy?

I agree With drloris 100%!

Shapejs co-creators are the most important thing ( By a Long shot)!
The improved IDE and documentation is great but continued work on these things without shapejs co-creators Is a mistake.
I think that it is like making a comfy leather seat for a car that you haven't made the wheels for yet.

I look forward to your updates.

This is definitely #1 on my wish list. I've got a bunch of things I can experiment with, but the end goal for most of them is the sale. Most of my ideas are around personalized products... but they really need more fine-tuning ability than the basic customizer we have public access to. Not insanely complex stuff. Being able to select different fonts, or overlay an image that's larger than my base item (keeping just the parts that overlap... like putting an image on the face of a coin. Today the only option is whatever square or rectangle fits inside that circular face, but ShapeJS v2 (or 1, for that matter - if I could get access to it) solves that.

I totally understand the way things work in app development, but I'd really hate to see what you guys have put into ShapeJS over the last few months go stale because it wasn't integrated into the Shapeways Marketplace. I'm surprised getting scriptable co-creators isn't on the fast track already. 3d printing in general is very cool and I'm having fun with it - but I think the only way to have a sustainable shop in the long run is to target the printed-product sales to items uniquely personalized to the customer in an automated way. In that way I'm much more a developer than a designer. I'd be more likely to make one product with several design-tweaking options than several products with just a small text/image block. Even if it required running ShapeJS on my own web server(s), I'd be on board... IF I could get the final output to route through sales, shipping, etc. automatically.

Thanks!
Tim

Language features...

Image3d, for sure. The ShapeJS v2 Coin example is very much like what I'd want to do with a couple of projects. A customer could select from a group of preset images or point to an image of their own to create custom buttons, cabinet knobs, etc. Like these... but with much nicer graphic and font options. I am really excited that this allows string URLs rather than a file object for parameters. That means I could have a whole set of predefined 'clipart'-like images that could be selectable via a dropdown box of text descriptions.

Text, Rotation, RingWrap... those would be essentials for sure. Here's a snapshot of a test I was doing on ShapeJS v1... the plan here was to have two textbox & font selections to create a toggle switch cover (off/on, Jeckyll/Hyde, Clean/Dirty, etc.). The test is clearly not printable, but it was as far as I needed to get to prove that I could merge this script with a plain disk and have the type of cover plate I wanted:


So those are a couple of examples of where I'm looking to start. Bullet-proofness - I'm in the 90% range. So far I haven't had any design rejections or print failures at Shapeways, but that's with the basic CustomMaker and manually-customized pieces. The main things I'd be concerned with in the type of projects I'd be starting with would be: Are the fonts that I allow to be chosen appropriate for the scale of the piece? Fonts with serifs, for example, are likely to have more problems at small scale than sans-serif. If I'm floating text or images, have I got support structures that would ensure no loose bodies. Like... that image above would be no good, but if the text was 3mm thick and sat on a 1mm thick grid of wire supports... would the grid be close enough to hold all the letters? One thing for sure, I would need to test all the extremes, look for conflicts and handle exceptions/limits. If a particular font was no good for really small models I wouldn't include it as an option. I'd be looking at it from an app developer's sort of perspective, and only release something to the general public after I'm fairly certain I'm doing as much as I can to protect them from making choices that wouldn't be printable.

At this point I'd see myself working by myself, and primarily using ShapeJS as a fine-tuning type mechanism (placing text/images on predefined objects). CustomMaker was a great start in terms of integrating the engine... my needs are just a little bit outside what it allows.

Thanks!!
Tim

I have taken to heart the advice from the v1 beta that ideally everything which is successfully generated should be printable - it just makes sense for a customer-facing interface, really. However, that's made harder when the only output is the model. For example, suppose I have a 10-char text box. This might potentially work fine for normal text, but fail on "MMMMMMMMMM". I think I was pondering on the possibility of returning an empty scene for that sort of case - don't remember if I actually tested that on a co-creator. It's not ideal, anyway. It would be nice to be able to return a sensible error message in this sort of 'text string' case, or where the parameters interact in some complex manner. I wouldn't mind the option of having a second script to screen the parameters and display a comment before the preview button is pushed.

Something I seriously missed in shapeJSv1 was the ability to read out the font metrices. The use-case I have in mind is setting the length of a pattern so that it doesn't interfere with the rendered text, but there are others.
Scaling text to fit a box is all very well, but it's not ideal when minimum thickness matters. It also has wierd edge cases - if a single full-stop('.') or hyphen('-') is entered in a square textbox it expands to enormous size, for example.


I'd also like to see a function to describe the cost, based on the actual manufacturing price - it's not nice to need to add a big margin (which all goes to Shapeways) when the material volume is variable, or risk the order failing to go through (and I don't know what the interaction with your structure-dependent pricing materials is going to be).

Also, it's a shame that existing shapejs co-creators don't leave "first to try" status. All three of the shapeJS custom makers in my shop have been successfully printed at least 4 times, and they all still say "first to try". I know that was described as a potential badge of honour for early buyers, but I think it's now widely regarded by designers as a thing which puts potential customers off.


Regarding the last question, I have been doing this by myself, but I don't have a problem with working with others.

Alan,

Since I never got added to the the old pilot. I don't have a track record of success rates for co-creators. however I expect that some will be bullet proof 100% or close and other that require more customer input will be far from it.

Here is an example of a cocreator that I am working on.


Using the Blend, BlurWidth and Rounding properties I was able to make the Engraving work for any fingerprint I tried.
It still needs work and of course will not ever be bulletproof since the customer has to upload an appropriate image.
This is an extreme case however I wanted to see what you had planned for testing a Cocreator like this where an image is needed from the customer.

Alan,

That sounds great.
Most of the projects that I have in mind the involve customized engravings.

In the Cocreator I think that the material that the customer has selected should be a property that the script can read.
This is important because even the difference between Gold Plated and Premium Silver has to be taken into account for the diameter of a ring in order for the ring to be true to size.

One solution would be to just have separate cocreators for each of the different materials.
However that would be a pain for the customer to navigate.

I think I forgot to mention... a key feature that I think I'd get a lot of mileage from is the Translations. One of my interest areas for modeling is guitar parts - knobs, cover plates, etc. I'm left handed, so all the tests that I run to use on my own hardware is backwards vs what the majority of customers would be looking for. Giving them a parameter input of left-or-right orientation and scripting the mirror-imaging would make things a lot simpler on my end. I have one plate that I put in my store as two different models - identical, except for the orientation of the text/image.

@wawwright - that ring is awesome. Now I'm thinking about making one to see if it could work as an iphone unlocker. Then I could key the phone to the ring instead of my finger, and use a slightly modified print so only the ring would unlock the phone

Hi Alan,

I have been experimenting with ShapeJS2 and one limitation that I have found is the inability to adjust UI parameters. There is an example in your documentation ( https://shapejs.shapeways.com/v2/tutorials/script-parameters - section 3) that illustrated the problem. Here the user asks for a 3mm thickness, the code adjusts this to 5mm in the background, but the user does not know and is expecting 3mm. If they go ahead and order a mug and it arrives with 5mm thickness they will be disappointed. The script needs to be able to reflect this thickness restriction to the user. This could be achieved by dynamically changing the rangeMin (and current value) of thickness in the UI based on the current values selected by the user for radius and height. WYSIWYG would then apply, as expected!

Thanks,

How about a string value that's passed back as a status/comment. It could just be left blank or just say 'Success' in most cases, but if the script needed to force any changes the coder could put something like 'Width limited to 3mm when height is under 2mm' or something, which displays under the preview.

My vote is for text to the user to explain what is happening, coupled to settable values in the UI to force compliance and ensure printability.

In this scenario and using the ShapeJS2 mug example, the rangeMin for thickness could be set permanently at 3mm - probably less confusing to users if it always has the same range...? However if the user tried to reduce the value below 5mm a warning/explanation would be given and the value returned to 5mm.