Ability to understand the graph hierarchy of RefSys, so it can be used to optimize the rendering output

[ghost]

The idea here is simple.

If you only change the code for a single part, you would only wish to output the polygon (STL or collada) for that part of those it also changes.

This way the GUI layer will only need to make an update for those parts, rather than regenerate the whole model.

I assume this is NOT implemented yet ?

I am thinking that the compilation stage can use reflection to output a serialisable description of these linkages so that it is understood.

This will allow scaling the creation of the model in a Map Reduce type logic across many nodes for large speed up on complex models whihc i intend to work n with this code.

It would also allow the GUI to show to the end use this relationship between parts of the whole model, and to be taken to the code where that part applies.

Pretty nice i think to maximise the usability of this library.

The serialisation aspect of the linkages i am not sure how to do in c++ myself.

Any ideas / thoughts about this wish ?

[avalero]

Wow :)

Linkage is already implemented, works well but it's not as "mathematically" good as I would like. Need time to think about it. Regarding the RefSys, you do not change it on the part you modify, but when you serialize you propagate all the geometric operations to the RefSys in order to have the final transformed RefSys.

I have not worried about "compilation timing" up to now, as in fact it only takes milliseconds for the models I am used to work with, but for greater models could be different.

As for a GUI. That's a TODO that unfortunately is delaying. I am not anymore at the University (unfortunately) and have few free time to work on this.

On Mon, Mar 18, 2013 at 12:51 PM, Gerard Webb [email protected]:

The idea here is simple.

If you only change the code for a single part, you would only wish to output the polygon (STL or collada) for that part of those it also changes.

This way the GUI layer will only need to make an update for those parts, rather than regenerate the whole model.

I assume this is NOT implemented yet ?

I am thinking that the compilation stage can use reflection to output a serialisable description of these linkages so that it is understood.

This will allow scaling the creation of the model in a Map Reduce type logic across many nodes for large speed up on complex models whihc i intend to work n with this code.

It would also allow the GUI to show to the end use this relationship between parts of the whole model, and to be taken to the code where that part applies.

Pretty nice i think to maximise the usability of this library.

The serialisation aspect of the linkages i am not sure how to do in c++ myself.

Any ideas / thoughts about this wish ?

— Reply to this email directly or view it on GitHubhttps://github.com/avalero/OOML/issues/10 .

[ghost]

Hey.

Just to be clear i am happy to do all this myself. I am only wanting to raise the topic of the relationships between each part being understandable so that it can be reflected on and the architecture extended further. I have no idea how this code base works fully yet and need to get it compiling in windows in VS first.

Otherwise i am just asking stupid questions.

This is a decent exampl of what we are talking about. https://github.com/avalero/OOML/blob/master/test/attachment.cpp

[avalero]

I am not sure I have understood the issue.

Currently you declare links for Component_1. When you move Component_2 to some link of Component_1 it applies a translation and a rotation to make the RefSys of Component_2 match with the selected Link of Component_1.

Next step is to match Links with LInks. I have planned to do this this weekend and document it on the wiki :)

[ghost]

its a freaking nice design and allows so much to be done with this library.

thanks for offering to write up a wiki article on it. I hope its not too much trouble, but it will really help me get my head around it.

f you do the wiki article it will be nice for me and others if you base it on an actual test in you tests source i feel. Avoids any confusion.

g

On 18 March 2013 13:53, Alberto Valero-Gómez [email protected]:

I am not sure I have understood the issue.

Currently you declare links for Component_1. When you move Component_2 to some link of Component_1 it applies a translation and a rotation to make the RefSys of Component_2 match with the selected Link of Component_1.

Next step is to match Links with LInks. I have planned to do this this weekend and document it on the wiki :)

— Reply to this email directly or view it on GitHubhttps://github.com/avalero/OOML/issues/10#issuecomment-15052953 .

Contact details: +49 1573 693 8595 (germany) +46 73 364 67 96 (sweden) skype: gedw99