hey- collada conversion to gltf

[ghost]

this is really outstanding framework.

i am just saying hi, as i would be happy to contribute to this.

i am wondering if there is any web backend code to help with loading up collada files, and saving them to the server hard drive ?
I use go lang for serve stuff these days. I was using nodejs etc, but have found go to be more to my needs.

[tparisi]

Hi Ged - thanks for the compliment!

Are you looking for a module to upload COLLADA and convert to glTF?

[ghost]

Well its not vital. I am hacking on the code now and finding pretty good speed just using collada models as they are. Quite fast.

But the gltf format is faster, and so its more of a future optimization i feel.

to be honest i am a bit in to minds on this. Keepng things as collada will allow glamjs or vizi to do client side manupulation directly of the collada inside an import if needed. Pretty damn cool !

But having gltf, means that you can change the insides client side, but only the pose.

So both is good, but for different use cases i feel.

[tparisi]

My idea is that, once a model is imported, you can still manipulate everything about it. If it's a COLLADA or glTF model, once it is imported you can access individual elements, trigger animations, and mess with document structure all you want. But I haven't implemented any of that yet.

[ghost]

i can convert collada to gltf. I am more interested in using it in webgl, and accessing its data structure.

If this is something currently present in vizi, would really help me move forward.
i have been getting decent speed with collada, but gltf will be better i am sure.

i am also wondering about usng flatbuffers for encapsulation aspects later, but just an idea currently.

[tparisi]

This is already present in Vizi and accessible in GLAM in that you can use a glTF file in the tag. However, GLAM doesn't yet allow you access the innards of the imported scene e.g. to trigger animations or toggle lights. I need to add a getImportedDocument() method to the resulting import element.

There is one more issue: the glTF loader in Vizi is based on the Three.js glTF loader I wrote and submitted to Three.js. It is out of sync with the latest COLLADA->glTF converter. I am in the process of updating this loader code and should have fixes this week.

[ghost]

hey Tony

Ah i thought it might be there. Really great. Will be interesting to do some benchmarks.
I will wait them for the code bases to sync though :)

[tparisi]

@gedw99 let's start talking about the COLLADA, glTF and issues next week ok? I have some things in the works

[ghost]

hey toni,

i started hacking on OsgJS. Its Open Scene Graph but for JS.
Check it out:
http://osgjs.org/

its allow the open scene graph data model to be exported to a JSON structure.
then with the OSGJS API and framework you can suck up the OSG json data model and manipulate it.
Its very nice to use an API that has been developed over 10 to 20 years of refinement.

Its also being extended quickly too.

so it might be another option as a webgl framework, instead of threejs that is currently used (if i remember correctly).

Curious what you think about OSGJS, and also its relationship to glam.

I dont have a ton of time at the moment, due to work commitments. So dont expect too much involvement on my side.

[tparisi]

Howdy Ged - no worries... dive in when you can. I just wanted you to know that I'm getting back to doing this.

I'll have a look at OSG. GLAM can be fairly dependent of the rendering layer, but if I ever decide to make it extensible (probably through Web Components) then we will need to address which APIs can be used to do the extending. It gets tricky.

[ghost]

One thing I see as very powerful with glam is to use material design polymer web components with your 3d web components. Hoping that its aligned with you ?

The other thing is the computational side of things. Have you seen furiousjs ? It is a very nice opengl / webgl and opencl context framework. It would make a create base for the future. If the device supports opencl ( like peoples Mac book) then we can do computation there, and if not then on the CPU.

Lastly, I am interested in spreading the computation between cloud and devices. A crdt data model is the basis for that. I worked on that before. This is the basis of cap their and hence paxos. On a web browser the indexdb can be the equivalent of the server side database. All that is needed then is a graph overlay of the computation tree ( which is itself modelled and replicated based on crdt) and you can split the computation based on the graph vertex boundary at runtime or design time.

That's some of the things glam can facilitate due to its web component focus I feel.

I am working on the above aspects when I get time :), but hoping you find it useful and that I can help shape glamjs to facilitate the above architecture ??

[tparisi]

We will definitely be moving toward a Web Components design. Possibly the Material design approach too... as appropriate.

I would love people to be able to experiment with compute and GLAM at some point. For my personal use that's a long way out because I want to know that the support is there in all the browsers before I invest too much time in it. BUT if others want to start playing around...

First things first, we are going to get a beta of what we have in January. Then we are going to start experimenting with Web Components.