Emerson

Hi! Supposing I have many spheres (jit.gl.gridshape) on the scene and I want to write index numbers on the surfaces of most of them. Is it necessary to dedicate a separate jit.gl.texture object for each numbered sphere or is there a workaround?

Hi! Supposing I have many spheres (jit.gl.gridshape) on the scene and I want to write index numbers on the surfaces of most of them. Is it n

how-many-jit-gl-texture-objects

you can create a "textue atlas" with all the numbers and then use tex_map 1 and tex_plane_s/t to map them.

unfortunately the tex_plane_s/t use is archaic and not intuitive, but it works. you can even use it with jit.gl.multiple.

use this snippet to make things slightly more intuitive:

you can create a "textue atlas" with all the numbers and then use tex_map 1 and tex_plane_s/t to map them. 

unfortunately the tex_plane_s/t use is archaic and not intuitive, but it works. you can even use it with jit.gl.multiple. 

here's a very old patch i made that uses the above technique with jit.gl.multiple to map key object output to locations in a font atlas using tex_plane_s/t.

in this case the math takes into account the characters in the font atlas are 16 x 16, but that's about the only hint i can give to how the jit.expr math works.

gl.multiple_texplane.maxpat

font1.png

That's a fantastic patch, thank you.About jit.gl.multiple: I'm trying to include user interaction and make all shapes selectable by mouse to get the individual object "name"s from jit.gl.picker, so I think I cannot use jit.gl.multiple for that but I have to create shapes individually. I'm not experienced in Jitter so I have to ask with apologies: if this is adaptable to use without jit.gl.multiple (for the purpose I explained), can you give other hints in that direction?

IMO the best solution for mouse picking with gl.multiple is to use some jit.phys objects for this (phys.multiple phys.picker) in conjunction with the gl.multiple.

if desired, you can set @dynamics 0 on your jit.phys.world to so that you are only using the collisions functionality of the physics simulation.

for an example of using phys.picker with phys.multiple for mouse picking

search the file browser for phys.multiple.picking.maxpat for an example of using phys.picker with phys.multiple for mouse picking

here's a modified version of that example patch that removes dynamics and simplifies the setup a bit:

@ROB RAMIREZ thank you very much for your posts.Creating the shapes literally on a matrix grid and then trying to distribute them into what I have in mind (a 3d construction of varying lengths of hierarchically connected circular orbits to represent my tree structure in response to user's input to solve a problem) can be a too far solution to cope with. I planned many details for the initialization by patcher-scripting in JS for coordinate calculations and node connections especially; and to get the identity of the clicked shape I'll code the names by placing indices between letters to extract each index, for instance. I was just wondering if a modular texture solution could be found where I can programmatically connect gridshape boxes in patcher in order not to multiply the load, which I guess on the average will be around 5000 shapes. But if it will result the same in terms of performance, the same number of texture providing object groups (my current solution for individual shapes is a simple message->jit.lcd->jit.gl.texture combination) can be created in loops too. So my question was about the texture, but while at it, can I also ask (since the numbers are quite big), in the mass creation process of the jitter objects if I set .hidden to 1 and use .hiddenconnect will that make a difference to lessen the load? And in a closed subpatcher?

Are there other things you can advise for this situation?

@ROB RAMIREZ thank you very much for your posts.Creating the shapes literally on a matrix grid and then trying to distribute them into what I have in mind (a 3d construction of varying lengths of hierarchically connected circular orbits to represent my tree structure in response to user's input to solve a problem) can be a too far solution to cope with. I planned many details for the initialization by patcher-scripting in JS for coordinate calculations and node connections especially; and to get the identity of the clicked shape I'll code the names by placing indices between letters to extract each index, for instance. I was just wondering if a modular texture solution could be found where I can programmatically connect gridshape boxes in patcher in order not to multiply the load, which I guess on the average will be around 5000 shapes. But if it will result the same in terms of performance, the same number of texture providing object groups (my current solution for individual shapes is a simple message->jit.lcd->jit.gl.texture combination) can be created in loops too. So my question was about the texture, but while at it, can I also ask (since the numbers are quite big), in the mass creation process of the jitter objects if I set .hidden to 1 and use .hiddenconnect will that make a difference to lessen the load? And in a closed subpatcher?
Are there other things you can advise for this situation?

How many jit.gl.texture objects