Thanks for contributing!

Some feedback in order to get this merged:

• You'll have to remove the quad_test folder and create a minimal example script in the examples folder instead.
• Since you've changed the implementation of MeshBasicMaterial to support quads geometry, we need to check and evaluate what happens if you disable wireframe mode. Does that also work properly?

BTW: this repo is autoformatted with black, and we check linting errors with flake8. You can install both using pip install -U black flake8. Then you can use black . and flake8 . to autoformat and lint, respectively.

Thanks for contributing!

Some feedback in order to get this merged:

• You'll have to remove the quad_test folder and create a minimal example script in the examples folder instead.
• Since you've changed the implementation of MeshBasicMaterial to support quads geometry, we need to check and evaluate what happens if you disable wireframe mode. Does that also work properly?

Yep, without the wireframe mode it paints the quads as expected.

@almarklein Holy Zeus! ⚡
Could the example issue originate from bleeding edge wgpu?
I can't reproduce it, I have the wgpu version from pypi.
Can you move around the scene? because there is a controller implemented.
Can you switch between modes when pressing 1,2,3?

I was on holiday, so could not check earlier.

Could the example issue originate from bleeding edge wgpu? I can't reproduce it, I have the wgpu version from pypi.

I tried with wgpu-py from pypi, but nope, same result :)

Can you move around the scene? because there is a controller implemented. Can you switch between modes when pressing 1,2,3?

Everything works as expected, except that it's a saw-shape instead of a strip of quads.

I suspect there's a subtle detail in the shader that makes certain values zero. I'll have a more proper look early next week.

Is this correct for nr 3?

The issue was that the indices were int64, which the GPU cannot handle. Why it does work for you is beyond me. We should add a check to guard against that ... I created #579 for that. For this PR, you can simply indices.astype(np.int32) somewhere.

Just wanted to chime in and show some appreciation here; the persistence and collaboration is a joy to see! Awesome to have quad support in pygfx soon. We're almost there!

@almarklein that doesn't look right.

The face colour should be a gradient stop from white to black (higher Z to lower Z values).
There must be something else going on.

I did a fresh install on my home pc, and it's working as expected.

@almarklein that doesn't look right.

I was afraid it didn't 😄. I looked into it, and it's the same problem: the texcoords are int64.

@almarklein that doesn't look right.

I was afraid it didn't 😄. I looked into it, and it's the same problem: the texcoords are int64.

It's weird that it works on both my work and home computer.
Maybe my python + numpy version converts the ints to int32 and yours dont?
or my gpu supports int64?

I tried starting the example by defining the dtype as int64 and it doesnt load.

    gfx.Geometry(indices=indices.astype(np.int64),
  File "C:\Python311\Lib\site-packages\pygfx\geometries\_base.py", line 60, in __init__
    format = resource.format
             ^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\pygfx\resources\_buffer.py", line 140, in format
    self._store["format"] = format_from_memoryview(self.mem)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python311\Lib\site-packages\pygfx\resources\_buffer.py", line 236, in format_from_memoryview
    raise TypeError(
TypeError: Cannot convert 'q' to vertex format. Maybe specify format?

I am using python 3.11.3, numpy > 1.24, gpu: nvidia 1030gt on my work computer
Home pc - python 3.11.3 numpy > 1.24, gpu amd radeon 570

Wow, there's two things at play here: I think indeed your numpy version defaults to int32 for the arrays created in the example.

Also, on my system, when the int64 array is converted to a memoryview, that memotyview reports a format of "l", which means 32bit. See https://docs.python.org/3/library/struct.html#format-characters. This is strange. Your machine reports "q" as expected. This is why the error was not caught on my machine, and the example ran, although broken.

I'm working on a pr to fix that.

@almarklein you must be using Linux right? I read that on windows the numpy dtype defaults to in32 unless it cant be represented as int32. On other platforms it defaults to int64.

But I guess thats a good bug caught on memory view :)

I read that on windows the numpy dtype defaults to in32 unless it cant be represented as int32. On other platforms it defaults to int64.

How convenient 😕. So if a Windows user posts code online, any Linux/MacOS user that want to run that code, may get an error from pygfx ...

Ok, I tested the example again:

• Added dtype where needed to make it work.
• Moved example to feature directory and updated the docstring so it appears nicely in the gallery docs.
• I found that the winding-fixing did not work for quads, so I fixed that.
• The picking was also not correct - because I gave wrong/incomplete directions - they now also work.

@almarklein Thanks a lot for the fixes! I am excited to see this in the gallery section! :D

Many thanks for your contribution @sharon92 ❤️

Yeah, great to see these improvements landed!