select any

[lazarusA]

I'm satisfied with the current status. And it does the job. I tried to tackle all corner cases, and see that everything works, but for sure there must be some hidden bug or use case I didn't catch. I used Gemini to find solutions and possible bugs in this transition.

NaN webgpu compute enhanced.

• Before (main)

• After

UI sliders update.

Pull Request Summary (by Gemini, but is accurate)

This pull request introduces a significant round of updates focusing on a major new workflow for multidimensional variable selection, layout responsiveness, rendering performance with WebGPU/WebGL, data handling for Zarr stores, and general UI/UX improvements across the core components.

Major Highlight: Multidimensional Variable Selection

• DimSlider Workflow: Introduced and refined the powerful DimSlider components workflow. This new system allows users to intuitively slice, filter, and select variables at will from complex, multidimensional datasets. It fundamentally improves how users navigate and visualize multi-variable Zarr data.

Key Features & Performance

• Optimized Time Combobox: Refactored the TimeCombobox and MetaDimSelector with windowing and scrolling improvements. This dramatically increases performance when handling datasets with a massive number of input dates.
• Improved Zarr Data Loaders: Enhanced GetArray, dataFetchers, and utils to handle packed chunks, flat datasets (isFlat), and 2D variables.
• Enhanced Computation & Memory Management: Fixed index memory strides and fixed issues where NaN and Infinity values were propagating incorrectly during 1-variable and 2-variable statistics computation.
• Playback Controls: Added support to "play" the timeline in any direction.

UI & Layout Refinements

• Responsive Dialogs & Popovers: Moved Attributes, Variables, and Colorbar details to use Dialog components (especially on mobile) while retaining Popover on desktop when appropriate.
• MetaDimSelector Redesign: Redesigned the data shape, selection, and chunk shape summary readouts. Relocated the Plot button to the right for a better layout flow.
• Responsive Alerts & Containers: The "Selection won't fit in Cache" warning has been updated to use muted, responsive UI alerts instead of hardcoded red backgrounds. Removed hardcoded fixed widths and borders from outer containers to prevent unwanted horizontal scrolling on mobile.
• UX Polish: Added loading spinners when variables are clicked, preventing empty boxes from displaying while metadata fetches. Dates with hours are now appropriately formatted and handled.

Rendering & Plotting (WebGL/WebGPU)

• Firefox Compatibility: Resolved WebGL issues specific to Firefox.
• Shader Enhancements: Updates to glsl3 and specialized vertex shaders for specific rendering use cases (vertex.glsl, LandingVertex.glsl, etc).
• Plotting Fixes: Adjustments to AxisLines, FlatMap, and Sphere mapping to correctly pass the right indices and coordinate rules.

---

Changed Files Breakdown

• UI/Components: MetaDimSelector.tsx, TimeCombobox.tsx, Variables.tsx, MetaData.tsx, Colorbar.tsx, PlayButton.tsx
• Plotting & WebGL: Plot.tsx, FlatMap.tsx, AxisLines.tsx, WGSLShaders.ts, webGPU.ts, multiple *.glsl files.
• Data & Zarr: GetArray.ts, dataFetchers.ts, utils.ts, GlobalStore.ts

[gemini-code-assist]

Code Review

This pull request introduces multi-dimensional slicing and custom axis mapping to the Zarr store and visualization components, allowing users to map arbitrary dimensions to the X, Y, and Z axes. It adds a comprehensive set of DimSlicer UI components, updates data fetching and chunk copying logic to support arbitrary slicing, and updates shaders to GLSL 3.0 syntax. The review feedback highlights a critical issue where zDimIndex defaults to -1 when unmapped, breaking 3D rendering, as well as several bugs in MetaDimSelector.tsx where parsing inclusive slice stop indices (especially when the index is 0) fails to handle the exclusive nature of Zarr slices correctly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[lazarusA]

do we revert again? and find a different approach for transformations? or is there a solution for this issue while keeping the textures approach ?

[TheJeran]

I'll look now. There was never any error message posted and I haven't gotten around to looking at FF.

[TheJeran]

Can't replicate.

[lazarusA]

it needs NaNs, that's why my screenshots are for transpiration. In all browsers? Firefox included?

[TheJeran]

That image is FF.

I don't have access to safari.

[lazarusA]

this is my Firefox output

Version

Version 152.0.5 (64-bit)

[TheJeran]

Ok, that shows what the issue is.

I looked, and apparently Firefox (And chrome for that matter) on iOS isn't even firefox. It's just a wrapper around Safaris webkit so it's compiled differently from Windows/Linux firefox.

https://adactio.medium.com/web-browsers-on-ios-b120a9a75cce

So yet another annoying variable to mess with.

[TheJeran]

Does it only not work on Transpiration?

That error tells me it should fail on any variable

[lazarusA]

Well, not exactly the same, safari is fine

[lazarusA]

Does it only not work on Transpiration?

That error tells me it should fail on any variable

indeed, it fails also for other variables.

[lazarusA]

So yet another annoying variable to mess with.

yes, but we need to make sure it works in as many browsers as possible, after all this is browzarr

[TheJeran]

Okay, I think we had an issue very similar to this before with texture order. I'll do a little research.

[lazarusA]

You could start from the solution. Which is the Array - idx approach, which is making sure there are no such issues.

[TheJeran]

Can you verify if this happens in all shaders: points, sphere, sphere blocks, flat, flat blocks

[lazarusA]

using usePaddedTextures is better?

or, will this also pose issues?

Gemini's diagnosis:

This comes down to a strict limitation in how WebGL (the underlying rendering engine used by Three.js) and its shader language (GLSL) handle memory compared to Javascript.

Here is why each of those pieces is critical:

1. The Number 14 (The WebGL Constraint)

In Javascript, arrays can grow and shrink dynamically. However, in WebGL shaders, array sizes must be statically defined and fixed at compile time.
Somewhere in your custom shaders, a uniform is declared with a fixed size of 14, something like:

uniform sampler2D map[14]; // or sampler3D

WebGL is extremely strict about memory. If the shader expects exactly 14 textures but your Javascript only passes in 3, the shader program crashes. Firefox strictly enforces this WebGL specification, causing the render to break. Chrome is notoriously a bit more lenient and will sometimes silently ignore missing uniform array elements if the shader never explicitly accesses them, which is why it might have worked there.

2. The Array (Array.from({ length: 14 }))

Because of that strict WebGL rule, we must guarantee that Three.js always sends an array of exactly 14 textures to the GPU, no matter how many actual textures you have for a given dataset. Array.from({ length: 14 }) forcefully generates an array of exactly 14 slots for us to fill, padding the data to the required size.

3. The idx (textures?.[idx] ?? textures?.[0])

Since we generated a brand new 14-slot array, we need to decide what goes in each slot. This mapping function loops through indices 0 to 13 (represented by idx):

• textures?.[idx]: First, we try to grab the actual texture for that index if it exists in your real data.
• ?? textures?.[0]: If idx is out-of-bounds (for example, you only gave it 5 textures, but the loop is on index 8), it falls back to the very first texture (textures[0]).

By falling back to the first texture, we ensure that the remaining padding slots in the 14-item array are filled with valid WebGL Texture data rather than undefined or null, completely satisfying Firefox and the WebGL compiler without affecting what you actually see visually on the plot!

[TheJeran]

So does it not work in every render method? I want to understand the problem fully before implementing a fix.

[lazarusA]

no consistently. Sometimes if you are lucky the only one working is point clouds. And other times not even that one works.

[TheJeran]

Okay, so I have an understanding what is happening.
Basically, the texture array preallocated in the shader assumes there are 14 textures of a specific type. Then the sampling function loops over all 14 (although they aren't all used). When the sampler sees an unallocated memory pointer it defaults to sampling from the first texture index. This is the first texture in the array in all other browsers. But I guess in iOS Firefox it puts the colormap texture there. So now the 3D sampler sees a 2D texture and just says - okay well this isn't going to work and shuts it all down.

If I am correct, it should render 2D data. So like the biomes data from seasfire should render properly. Would you please check this?

The padded array (in its current approach) I believe is allocating all of that memory on the GPU which should be problematic with large textures. Worst case scenario usePaddedTextures needs to return an empty DataTexture of the correct type instead of the texture at index 0. That way it's allocated without taking up space.

Unfortunately the simple fix isn't compatible with WebGL only regular OpenGL.

Also my Time selector still does this

[lazarusA]

yes, only 2D data in your commit works:

[lazarusA]

Also my Time selector still does this

what's is wrong with that? Sometimes dates will contain hours/minutes, hence start/end don't fit in the same row, so I move the other one to a new row. That was intentional. Suggestions? centered doesnt look better.

[TheJeran]

Okay, great to know I am understanding what is happening.

When we talked, I had mentioned it and you said it was fixed so I didn't think this was intentional. I guess we were talking about two different things. I would just let them overflow and hide it. Maybe drop the font down 1pt as well.

[lazarusA]

please verify this:

The padded array (in its current approach) I believe is allocating all of that memory on the GPU which should be problematic with large textures. Worst case scenario usePaddedTextures needs to return an empty DataTexture of the correct type instead of the texture at index 0. That way it's allocated without taking up space.

Unfortunately the simple fix isn't compatible with WebGL only regular OpenGL.

if so, propose/push a commit solution.

[TheJeran]

I can't verify and don't see any increase in VRAM with extra array lengths. I think maybe they are just pointers then.

Alright, let's go with the usePaddedTextures approach. I think this will also fix a bug I couldn't replicate in the past where it would sometimes fail to render when swapping around variables. I would get the two samplers using the same texture GL error message but could never consistently reproduce it to trace the cause.