ETA on ShapeJS2 Cocreators?

Discussion in 'ShapeJS' started by twoshay, Feb 22, 2016.

  1. twoshay
    twoshay Well-Known Member
    I could just be looking in the wrong places... but is ShapeJS2 available outside the demo page at ? I'm just itching to try a few things in an actual automated cocreator scenario.

    Tim Shay
  2. wawwright
    wawwright Active Member
    I second THAT!
    I'm excited to get my creators in my shop and for sale.
  3. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    We understand that the ultimate value of ShapeJS is in the ability to create your own Creators. If we think of this as a three step process -
    the first was to create and iterate on ShapeJS - the work on that has got us to where we are now with ShapeJS 2.0. The second step was to make
    it as easy as possible for Developers to both design in code and to build Creators - that is why we built the Integrated Development Environment
    for ShapeJS and created a bunch of new example and tutorial content. The third step will be to build Creators into the Shapeways Shop experience - making it possible to expose Creators built by you using Shape JS IDE to Shoppers on Shapeways.

    We don't yet have a date set to start work on the third phase. What I can promise is that I will post an update on the status of this project
    in this thread every month until we start work on it, and every week after that. If you are passionate about ShapeJS and want to be able to
    create your own Creators and have them be available on Shapeways for Shoppers to come and buy custom products - let us know! There are a
    million things we could choose to work on at any given time and only so many hands on the team - hearing from the Community what is most
    important to you helps us prioritize. So if this is a priority for you - let us know! The other thing you can do is to contribute to the
    ShapeJS knowledge base by experimenting and sharing your experience with others - ShapeJS is only as good as the Developers who use it.
  4. drloris
    drloris Well-Known Member
    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?
  5. wawwright
    wawwright Active Member
    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.
  6. twoshay
    twoshay Well-Known Member
    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.

  7. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    Thank you for your comments.

    We have a few questions for you.

    Are there any ShapeJS language features you think are necessary to create the experiences you want?

    How bullet-proof are your concepts, is everything printable(wallthickness, sizes etc) or does the user need to understand the material?

    Do you see yourself creating these by yourselves or by working with others such as a designer, programmer or marketer?
  8. twoshay
    twoshay Well-Known Member
    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.

  9. drloris
    drloris Well-Known Member
    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.
  10. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    We're working on a auto-tester for scripts that will give you a printability report for the script. The goal is to test enough of the parameter space to give you a sense of how printable the parameter space is. Before you set a script for sale it will go through this tester. For scripts with a high enough success rate(100% is great!) we're thinking of awarding a Shopper badge. Those creators with a Shopper badge will get higher placement in searches, more marketing support etc.

    I'll look into the font metrics and first to try states for Shapes 2.0. We've also added script sourced fonts so you can now use whatever font you want to help printability. We're looking closely at the pricing model and I hope the current logic is improved as I agree the max volume concept is very limiting.

  11. wawwright
    wawwright Active Member

    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.

  12. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    The way I've been thinking about testing images is to have a suite of images in the test suite that range from nice thick line art to almost random noise. We get a wide range of images from users on the image popper :)

    Since your using the geometry for engraving instead of wholesale making the piece from user geometry I would expect your creator to pass if coded correctly.

    We are also looking into image analysis operations that would allow a script to automatically thicken lines that are too thin for the material. Not sure this will make the initial launch but we're looking into it.

  13. wawwright
    wawwright Active Member

    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.
  14. twoshay
    twoshay Well-Known Member
    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 :)
  15. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    We're launching variants soon which should cover this concept, ie basically a single product that contains two models one for left handed and one for right. That said it would be easy to offer an enumeration on a ShapeJS script todo it as well.

  16. DB24
    DB24 Member
    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 ( - 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!

  17. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    Thanks for the reminder. We have a proposed solution for this which is in fact allow the script author to change the ranges when executing the script. There is some push back from the user interface folks in this. Ie if I had set the thickness to 4mm and then the script decides to change it too 5mm based on my radius change, how much notification is needed. Just an automatic change(script author knows best), up to a full alert.

    We'll have to discuss the relative importance of this change before going live with the first version. My feeling is there are bunch of useful scripts that could be done that don't require this. So likely that says rev 2. But I agree there are plenty of scripts that would need this type of logic especially if a single script is trying to handle multiple materials or large ranges of product size.
  18. twoshay
    twoshay Well-Known Member
    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.
  19. AlanHudson
    AlanHudson Shapeways Employee Dev Team
    Might work. We've been considering that feature for a different use-case, namely dealing with printability concerns with things like user-images.
    Ie you might analyze the user-image and determine it's inappropriate for your geometry generation(say too thin lines). In this case you need to get a message back to them so they understand what's wrong. Though I think changing the user-interface will be desirable as well for more complex items. That said we likely need to be thinking of keeping the ui simple with only a few parameters if we want shoppers to understand them. The drop off rate of complex interfaces is very steep with shoppers.

    I see this system as having two targets, shoppers and makers. Our first goal will be to solve the shopper case as its got much bigger profit potential. Even if I more want to use the maker-maker path for my projects.

  20. DB24
    DB24 Member
    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.