ekatrukha.bsky.social
Biophysics, cytoskeleton and self-disorganization
90 posts
1,036 followers
356 following
Regular Contributor
Active Commenter
comment in response to
post
Are you making tiny washboards so cells can finally do their laundry?
comment in response to
post
I'm glad you've found it entertaining!
Potential tomorrow's project:
DooM II in BigDataViewer with expanded HeLa cell as a first level and lysosomes as cacodemons 😛
comment in response to
post
ah, wront tag in the head, gonna add #bigvolumebrowser
comment in response to
post
That is it for today. Here is the last movie of 🧸 looking at microtubules obtained using expansion microscopy.
The current mess of a code is available here github.com/UU-cellbiolo...
(N/N)
comment in response to
post
oooh, it turns out the image is A B G R (in memory), but OpenGL expects R G B A byte order, doh.
So, after making almost every possible mistake, the final result is here!
I did not expect this to be finished in a day, yoohoo 🎆 (15/N)
comment in response to
post
Almost there. Uploaded UV and texture to GPU and changed the shaders.
So it looks almost ok, I think UV mapping is correct, but the color is not, for some reason.
Need to figure out why it is so red now. Probably some stupid mistake somewhere. (14/N)
comment in response to
post
Now I need to extract so-called UV coordinates, i.e. for each vertex, corresponding XY coordinates in the texture image. More buffer parsing (13/N)
comment in response to
post
The texture image includes recognizable fragments of band aids, applied to the model by its owner in an attempt to prevent 🧸 decomposition (12/N)
comment in response to
post
To keep the thread cohesive, turns out there are four textures: 'base color', 'occlusive', 'metallic roughness' and 'emissive'. I think the last three are for the complex scattering/emissive materials.
I was able to extract "base color" and it looks ok, like expected "teddy bear skin" (11/N)
comment in response to
post
At first I thought so too, but no. Investigation shows that all four images are RGB.
Turns out they are "base color", "emissive", "metallicRoughness" and "occlusion" textures. I think they made for more complex materials, I am going to get only "base color".
comment in response to
post
The texture object has four images, not one.
Eh?
Why four? Which one do I need? (10/N)
comment in response to
post
Love this error.
Are you ok, buddy?
We had some minor interference during teleportation.
comment in response to
post
Fixed. Finally, a nice view. Yoohoo!
Now I am going to try to extract a texture: a "skin" image that should be rendered on top of the mesh.
(9/N)
comment in response to
post
All right, almost there. The indices are loaded, but the normales (vectors specifying surface orientation) are wrong. So now basically it is kind of inside out, the outside is dark, but inside reflects light. Just need to change the order of indices in triangles (8/N)
comment in response to
post
In practice, triangles are often encoded by "vertex indices", to reduce the amount of data. So two triangles with the same edge will have vertex indices (0,1,2) and (1,2,3). So vertices are "reused", just 4 vertices (not 6) for 2 triangles.
Now I need to see where to get those indices. (7/N)
comment in response to
post
Next step is to render the surface as a collection of triangles.
The first attempt relies on my naive assumption that in an array of vertices the triangles are encoded sequentially: vertices (0,1,2) triangle 1, vertices (3,4,5) triangle 2, etc
Clearly, it is not the case (6/N)
comment in response to
post
All right, I can read the array of 3D vertices!
The final result looks correct, pretty much like a teddy bear.
I must say that in this rendering mode (without surface/depth), the tail somehow looks unintentionally ambiguous (5/N)
comment in response to
post
Hmmm, turns out it is a pretty complicated library, everything is stored as buffers. I am going to torture LLM for help (4/N)
comment in response to
post
For the file reading, I will be using github.com/javagl/JglTF java library. It looks pretty complicated, but let's see if I can first extract at least the positions of vertices (points) of the underlying mesh (3/N)
comment in response to
post
I've already obtained its 3D mesh/view using my phone and Polycam app (link poly.cam/capture/b31e...). So I know it is supposed to look like this (see below). I can download gbl format file, it is available via the link (2/N)
comment in response to
post
Ah, I see, this rounding allows them to "seamlessly" merge a couple of filament segments.
comment in response to
post
Good question! Top middle was harder. For the top right, the mesh shader calculates distance to rounded (whole numbers) coordinates values + threshold. For the top middle one needs to move to barycentric coordinates for each triangle (+threshold).
comment in response to
post
Just a bit of explanation. BVV has the coordinate system and perspective projection frustum setup organized as in pic1. So if we center a "volume cube" at the origin (pic2, cyan), what would be max scale so it fits frustum (pic2, orange). To answer, I shoot white and red rays to find intersections.
comment in response to
post
It is a new plugin/GUI on top of this fork of BVV github.com/UU-cellbiolo... It is supposed to work with multires. clipping, sources transformations, etc.
Maybe when it is done, we can add it to FIJI.
comment in response to
post
It's a very nice idea for the review. Usually, one has to collect all that info from companies separately. It should be very handy when purchasing a new system.
comment in response to
post
Yeah, constantly need to remember in which matrix/world you are now. But then when it works, it works. So if it looks right, the best control for me.
comment in response to
post
Feliz cumpleanos, weon! :-P