Jump to content

extrusion doc complete


Recommended Posts

That's one helluva document.  Phew... nice work Jeromino!


But you wait.  A change will happen in the framework, and all your playgrounds will go broken right now.  The playground always gets a very new version of BJS... so... heh.  Hold on for dear life!


But yes, you definitely set a brand new PG-per-doc record.  I think only you can surpass it.  :)


There is another Skywalker.  You've seen my 10-camera pain-in-the-butt playground?  And you've seen my talking playground.  Well, doesn't that give you a mad scientist idea to... take over the playground to make THE workshop?  The path, ribbon, tube, extrusion, SH... workshop!  Yay!


(The 10-camera demo is now slightly broken. The virtual joysticks don't shut off.  See?  I need to fix... ONE PG.)  ;)


Yep, the option is open to you.  A single playground...  with a massive pile of buttons and knobs to do jMesh stuff-with.  YAY!


There's only one (hundred) minor problem.  The amount of JS needed to "take over" the playground gui... is rather substantial.  That extra code can make it difficult for users to see the applicable code that is used for any given "sub-demo". 


But keep in mind that YOU can completely hijack that puppy, eliminating the RUN and other buttons, and do your own SELECTIVE displaying (a section of code)  shown in the (non-editable) editor window. 


Anything is possible... if you're willing to code a pile of JS for the needed dynamic HTML.  Then maybe get DK to hide it for you.


Maybe a "hack the playground gui" library could happen, and maybe Deltakosh would allow us to include it into the PG... under certain circumstances.  The playGoo lib.  Maybe it would be automatically loaded-in for playground scenes that have playgoo(); as their first line of code.


Another important thing:   scene.onDispose needs to be rather thorough IF you allow the user to select other demo scenes.  Without "cleaning house" upon exiting a scene, the user could get stuck inside Jerome's Ribbon-Blasting Lab gui... which looks almost nothing like the default playground gui anymore. 


In short, the gui needs correcting upon exit, or a complete reload of the playground.


All in all, half'n'half.  If you used "the lab" for ALL of your demo scenes (somehow), then if something changes in the framework, the "update" is not so overwhelming (workload-wise).  Just a thought.  You'd be turning a playground scene... into a specific-purposed application.  And if you played your cards right, you'd only need one.  At most, 4.  ;)


Some of the talking in your doc... could be moved to talking in your "lab".  Information panels!  And, maybe you would get the record for the world's largest playground scene!  YAY!  Half-megger!  But also keep in mind that text which is displayed in a playground scene... is not easy to translate to other languages.  So, give and take.  PG-talking while showing examples... is wonderful, and also not so wonderful.

Link to comment
Share on other sites

Thank you Wingy.

Yep, I'll think about migrating all this stuff somewhere else less dependant on engine changes....

But, in the same time, the links in the documentation illustrate the methods of the current engine version... so if the engine changes and breaks the PG working examples, well, the doc is to be rewritten too, isn't it ?

So far, I just followed DK's recommendations : write feature documentation in the doc site and give PG examples to illustrate with running code.


And I really like the PG. It's a huge tool :

- it's easy (embbed editor with autocompletion, syntax checking, etc),

- it's communatarian (threejs guys have many different PG-like tools, but very scattered ones),

- We can all share / compare / fix / debug / learn things on the same basis,

- I can put incremental learning for the doc :  I write once the full code, comment many lines and then make many eductational links to the same code by just un-commenting lines one after the other to achieve the final result step by step :)

Link to comment
Share on other sites

*nod*.  Yeah, broken PG's are always temporary.  The framework authors (like you) tend to try for backward compat.  I had 3 tutorial-referenced playgrounds stop working for awhile... when the vertical subdivisions parameter was added to CreateCylinder.  When it was first added, it wasn't optional.  All BJS cylinders worldwide... broke.  :)  But then the framework got re-adjusted... about a day after I updated my playgrounds.  Alright!  :)


Also keep in mind that you can make your Parametric Shapes doc... be a standard webpage stored anywhere.  (You know that already, of course).  HTML gives you quite a bit more power than .md... as you know.


But it's all cool.  I love the doc, and the system.  I'm going to do some mad scientist experiments with it... I can smell it.  :)


That thing where you had the particles flying around in a geometric pattern... that SOB is just WAY WAY cool.  Droooool.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...