va3c / ghva3c Goto Github PK

Since we are building a lines component in issue #2 , we'll need to adjust the Scene component to accept lines in addition to meshes and materials.

@mostaphaRoudsari told me the line component is a bummer. "why does the user need to mesh everything?!? Just convert it into the right kind of Three.js curve for them!".

He's right - we should be able to take any Grasshopper curve and create a three.js representation of it. I have to look into the Three.Object loader a bit more to see what types it can load. Lines and meshes are certainly a go, but the curve selection looked somewhat limited at a glance. Same goes for curve materials - it would be awesome to be able to do dashes and linewieghts and everything, but right now it looks like the loader doesn't support that stuff.

More to follow after some research, just wanted to get this down.

Create a component that defines a THREE.js MeshBasicMaterial.

Take a mesh with color data (and optional attribute names and values) and output a json representation of the mesh and a list of all necessary materials for the compiler to consume.

As I mentioned in #12, I've been using these components on a real project and have found one early design decision to be especially unfortunate ... during the hackathon we thought it made sense to combine meshes and materials in the collector component using typical grasshopper iteration to do the matching.

This is inconvenient when you have lists or trees of meshes where different items (or entire collections) want to be assigned different materials. It would be better if the material was an input to the geometry components. This is a closer fit to how three.js actually works: to make a geometry object, you need a mesh and a material. Objects are made of meshes and materials, and scenes are made of objects.

Rebuild all components. Make geometry components take materials as inputs, and make the collector component more general - it should just accept a data tree of geometry objects, and each one should already be assigned a material. Create grasshopper parameters to wrap around vA3C specific types like material, mesh, line, curve, etc.

If the WYSIWYG #12 idea works, we might be able to build a watch window in grasshopper. This would be our first dynamo > grasshopper functionality port, and I think it could be super useful. Credit goes to Matt Naugle in CORE studio for the idea - he's been asking for this for a while.

Write a component that takes any grasshopper geometry collection (or a va3c.json file) as an input, converts it to three.js json and bounces it off of a running instance of the node server described in #12, and renders the results in a WebBrowser contol object that is embedded in the grasshopper node and running a stripped down version of the vA3C viewer (meaning the component itself would contain this windows forms control object - the web browser pointing to our local server and running the vA3C viewer).

I have to give this a try as a prototype to be sure it's doable (can a WebBrowser control run webGL?, Will the navigation and everything work inside of grasshopper?, How d you do that to a GH component exactly?, etc) ... but it seems like it should be.

Looking at the read me, I see that the links point to very early work (http://va3c.github.io/viewer/grasshopper2.html at top of page for example) and there's no indication of the ongoing effort. I would be nice to see a few more links.

Also there are quite a few new sample files in the samples directory, but all are just the .GH files and no JSON files. It would be nice to have more files for testing and building demos...

I've been using (and developing) these for an actual project at TT, and have thought of a couple of new features and changes that would significantly help the workflow and UX.

We need a real-time vA3C viewer that previews the THREE.js model that the user is currently exporting. It takes too long to upload a file and see what it looks like - you should be able to see what the file looks like WHILE you are authoring it.

How to: build a little node server that runs locally and bounces our json from grasshopper to a client side vA3C viewer (a browser pointing to localhost:somePort). When a new .json file is generated, it is immediately streamed to the browser.

I did a little test today, and was able to start a node.js server with a c# program, and then connect to it from a local browser. I think it's totally doable...

Rename the va3c_geometry component to va3c_mesh. Add support for quad faces (do the conversion to triangles internally).

We need to be able to create materials for lines, and we'll need a LineMaterials input on the revised scene compiler component described in #6.

Inputs for this component should be a color and a linewidth. Output is a JSON representation of the material.

Am I exporting the mesh wrongly? Or using the viewer wrongly?

Somehow my mesh is appearing to be showing only half of the full mesh.

I wish I can solve this myself though have been stuck on this for a long time, will appreciate any advice!

stackoverflow question

@bhowes-tt, thank you very much for providing such an awesome library with GHvA3C! I've been wondering about the license of the project: https://va3c.github.io/ mentions the MIT License at the bottom - is this the license that holds for all the projects in va3c?

Create a component that takes a mesh and a list of colors (as well as optional attribute names and values) and outputs a json representation of the mesh, and materials for all of the necessary materials.

We'll do typical GH iteration in the component - if there are fewer colors than faces, we'll use the last color for all remaining faces. IF there are fewer faces then colors, we'll ignore the extra colors.

This will be useful for displaying Ladybug/Honeybee meshes, for example.

Add a lines component. This should take a grasshopper line and a color, and output a JSON representation of the line and a material to feed into the compiler.

I wonder if THREE.js lines can contain attributes just like meshes ... will have to have a look.

for all components.

and resolve opacity issue. It would also be nice to expose some more properties, but at the very least we need to distinguish between basic and non-basic materials.

Similar to #8, we should have a Brep component that takes care of meshing for the user. This could even be a cluster using the standard grasshopper mesh components.