Re: The cam, the object … a trigonometric love story
I'm okay now with jit.matrix, plane(s) in order to trigger calculations.
Imagine I have 30 abstractions with jitter gridshape or like inside (the fact the java instantiate the isn't important here because it happens one time only)
I have now 3 matrices:
– one for all object positions (fed at init time and some change when my moving objects move)
– one for cam position (basically now a triplet x,y,z , later with orientation stuff)
– the latest for all azimut/elevation/distance relative to cam for each object
Each abstraction needs to know aed in order to process that and react (distance, basically inactivate my gl object inside the abstraction concerned.
Now, I'm firing the calculation with the global qmetro on the left, instead of doing that IF a position (object OR cam) occurs.
I'm also using the qmetro trigger inside each abstraction to grab the concerned cell in the AED resulting matrix… in order to process that in the abstraction as said before.
Does it make sense ?
Where could I improve things ?
Actually, performances suck and, as I wrote, I didn't yet do any object design, only colored sphere without lighting :p