More Geometries

[rubydesign]

When working with geometries programmatically, the supported shapes are quite limited. I understand that if loading from file this does not matter, but i am constructing models and i guess other may want to too.

Especially two geometries would be useful:

• a plane with points given as an array (maybe around zero as a restriction)
• same as the plane, but extended by a configurable z

I will have to do the second for four corners anyway. I could make a pull for that at least to get a start?

[xeolabs]

Yes please, send over a PR - put them in this dir for now: https://github.com/xeolabs/xeogl/tree/master/examples/js/geometry

[rubydesign]

ok @xeolabs will do but i found a way to get around the problem for now. (The overhanging parts are covered in others)

But it is interesting to me (i studied physics) and i'll do it as soon as i have time.

btw, did you have a chance to look at the pull requests?

[rubydesign]

@xeolabs I tried to get my things to work after that rewrite. But. .

It seems that while the docs still say that one can update a boxGeometry center and xSize etc, the source seems to differ. And if i am reading this, there is way to change the boxGeometry after creation.

So what is the idea for manipulating models? Or have you given up on the whole idea of having an api?

[xeolabs]

I removed mutability from the Geometry primitives, just because it was complicating things and was a big complexity/maintenance bottleneck. As far as I was aware, nobody was using it (and I never had any use cases needing it).

You can however update xeogl.Geometry as long as you configure it to be uncompressed, and always pass in the same number of vertex attributes as it was configured with. This should work:

var geometry = new xeogl.Geometry({ 
    quantized: false, // Not compressed
    positions: [... ],
    indices: [...]
});

geometry.positions  = [...] // Must be same number of positions as given to constructor

So I'm not thinking of xeogl as a model editing library, more as a model visualization lib. Apologies if that's disruptive! In the rewrite, I needed to prioritize efficiency for rendering and the editability was too much to keep working while doing that.

Or have you given up on the whole idea of having an api?

Not sure what you mean by this one - could you clarify?

[rubydesign]

Actually i think the rewrite was a good move towards simplicity. It just took me a sec to adjust: I am now using the Entity and Model api's and find that more coherent. All change happens through the Transforms. I got everything to work and will continue with xeo, but do have a few suggestions and maybe a bug. I'll open new issues for those and close this, and open a pull if i get around to this.

I guess the api thing is what you call editing. But as i said, all is good, maybe a few small helpers more, but the simpler api is good