Geometric modeling kernel?

[Pryme8]

So I decided to crawl out of my hole for a minute now that I have chance to take a breath of fresh air I wanted to ask a question.  I have been working on a editor for BJS that includes a lot more robust geometry creation tools when I realized I dont even know what Geometry Kernel BJS is reliant on?  Is it a proprietary kernel or is it ACIS standard?  I am really close to being able to release my editor here at some point I just need a little more time to finish up some of the core features. 

I figured using openCASCADE as a example will get me going in the right direction, but I am kinda in a grey area over how bjs handles its geometry creation, but will go over that area of the script today and get a way better understanding. 

Am I living a pipe dream in thinking of deploying a independent geometry kernel?
http://dev.opencascade.org/doc/overview/html/technical_overview.html#OCCT_TOVW_SECTION_2
I am mainly interested in the Modeling Algorithms, as bjs seems to already have all the core features they describe.

Ive gotta get back to programing now though, and am just tossing this out there while I wrap up my paid jobs.

[NasimiAsl]

wait my answer for next day i try help you to make geometry base for BJS;)

[Pryme8]

I want to get the ability to model primitives before I release the preview to my editor so that would be very helpful.

[GameMonetize]

I'm not sure to understand the question but perhaps you can answer by yourself

here is the class responsible for every primitive we support (Ribbon here for instance)

https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.mesh.vertexData.ts#L421

[Pryme8]

Looks like I need to learn typescript... But just reading over this I think it will give me what I need for extending the geometry kernel to include 3D modeling tools like fillets and such... I think the way I am going to handle it is have Babylons methods create what ever simple geometry and keep its initial settings to be editable, but then once you have your basic primitive and want to edit it, you will flag it as editable and my editor will then use its methods to manipulate the mesh.

[Wingnut]

Hi P8!  You know, you need to store all your Hermites in Catmull ROM.  haha.  (too early for fillet and chamfer humor?)

In order to stay compatible with BJS, you need to use the vertexData object to define your geometry.  You can start with BJS primitives created with vertexData arrays, but you need to keep it there.  Set your primitives updatable as you say,  but you will need to add many vertices to (and remove a few from) a standard primitive... in order to accomplish chamfers and fillets, and you will be working with the vertexData's arrays.  If you leave the vertexData system, you will lose BJS compatibility (afaik).

In my opinion, it is easier to use math to "grow" the chamfer/fillet mesh, so the many added vertices are already included in the vertexData arrays of these extended primitives... upon creation.  Using a freehand editor to add/remove vertices and their indices, normals, uvs, colors, etc... is a big challenge.  Selecting which vertices... is everything, and welding gets involved.  Not an easy task, but maybe you're up for the challenge, P8.  I'm glad it's you and not me. 

Ya know, P8... they already make machines designed to cause pain and agony.  No need to program an  editor/modeler... to attain good pain.

Most people would just do their chamfer/fillet... in Blender, Unity, or Max... and then export to BJS.  Do you REALLY want to code another Blender?  Is it a wise use of your hours/brains?  In some circles, modeling is ONE thing, scene-layout is ANOTHER thing, and display-in-webGL is a THIRD thing.  Perhaps it is wise to take careful notice of the borders between those three activities.  Perhaps target your projects toward any ONE of those areas, but don't let your app cross those borders.  If your project has to cross one of those borders, write a DIFFERENT app for each area.

If you think about it, BJS is the third thing.  Blender is handling modeling and scene layout.  Some say that Blender modeling should be separate from Blender scene layout.  It is still a heavily debated issue.   But notice that BJS can import mesh models, and/or scene layouts.  We get both... from the other side of the border.  Our geometry-generation system is really an add-on to BJS, correct?  It is a modeling task, not a webGL displaying task.  The BJS editors... are really scene-layout devices, not modelers. 

In short (too late for that)... if you want modeling, write a modeler.  If you want scene layout, write a scene assembler.  If you want webGL displaying and lots of fun effects, use BJS.    Notice that I am continuing the train of thought from our PM's... trying to get you to treat BJS as a webGL "viewer" and not overload it with modeling and scene assembly tools. 

"Powered-by-BJS" is not the right approach.  Powered-by-JS is.  BJS is JUST one of the "modules" that your powered-by-JS will use.  Not overloaded, not modified.  It needs to stay as it is, and you need to talk to it using its normal unmodified interface.  That way, you can easily snap-on new versions of BJS as it evolves, and due to your "powered-by-JS" project ALWAYS following that interface STRICTLY... it's an easy update.

Just some thoughts... I doubt they are worth anything, but maybe.  heh.

[Pryme8]

Love the input!  And great points made, the one thing that I am leaning tword is using bjs as the main work horse for all my geometry creation and manipulation, I all ready have the classes and methods together to do things like select verticies and weld or delete them and am working on the slice functions now.  Keeping everything as vertex data is not a problem and TOWER actually manipulates the data and ports it back in...

 

anyways screw it I'm gonna work on it more any of my ideas for connecting all the dots is what I would be affraid of someone with more resources jacking but I kinda realize no one prolly would have the vision I have for the project so yeah here is the most active prototype for those interested:

http://pryme8.github.io/TOWER/

I just changed to a new program structure and GUI so none of the functionality is there from the prior alphas... But I already have scene and prefab assets handled for loading and exporting, and all standard transform tools and widgets along with global widgets and all editor cameras and views...  But yea the one I just posted is really just the starts of the new structure.

tower consists of a project object, scene objects, an object object (ha) and others that hold all bjs settings for that object and then when it constructs the scene depending on your order of objects in the scene organizer tower constructs your scenes procedurally from that.

anyays having all your model data your textures your sounds your scripts ect stored as a single text file and being able to load it in browser with a single js string will be one of the main points of TOWER...

as soon as I finish my real estate software this is on the plate and I know it sounds like I'm talking big sh$t but any thing I have mentioned I havhave figured out how to deploy so it's not just pipe dreams... It's just getting the time to do it all and making sure I don't miss anything big on the way.

[Wingnut]

Sounds good, looks good.  Well done.  Have you worn-out another keyboard since we last spoke? 

[NasimiAsl]

why i am a very busy man

[Pryme8]

Figured the more people we can get on board the more this will be a reality

[NasimiAsl]

hi i start make geometry by new algorithm

and make  walls but i work on for make GeometryBuilder Extension

first samples : 

http://www.babylonjs-playground.com/#1B40RE#8 

http://www.babylonjs-playground.com/#FT2RY#56  wall 

http://www.babylonjs-playground.com/#FT2RY#57  wall options

i start this stuff after i finish ShaderBuilder But if it help i can explain details for you

[Wingnut]

Cooooool!   I thought Jerome's way of making mesh (tubes, ribbons, paths, extrudes, etc) was a strange system, but NasimiAsl, your way is now #1 strange.  Strange is good, though. 

When I ran #57, my computer asked "Will this hurt?"

I answered "No, Naz code won't hurt us."

But after the run finished, my computer was tired, and took a nap.    (just kidding, of course)

I think I will enter-into the keyboard-selling business.  All you geometry scientists MUST be wearing them out quickly.  I could make BIG MONEY in keyboard sales.   

[NasimiAsl]

ps :  i dont know anybody can challage jerome ? i never wanna test