mosra/magnum

Lightweight and modular C++11/C++14 graphics middleware for games and dataviz

Vladimír Vondruš

@mosra

huh, why is Z last?

usually it's Z first, then Y then X

so a 2D Z slice is simply pixels<T>()[i]

pezcode

@pezcode

oh dear, you're right

Vladimír Vondruš

@mosra

in other words, for the pixels view the strided array view size should be image.size().flipped() :)

to answer your original question, if Z would really be last then pixels<T>().transposed<0, 2>()[i], where the transpose turns it from XYZ order to ZYX

pezcode

@pezcode

no you were right, z is the first dimension, I just got really confused in my head

Vladimír Vondruš

@mosra

i made this exact mistake several times myself also, so i learned to spot it :D

pezcode

@pezcode

so if I was trying to emulate pixels<T>()[i] with prefix/slice, how would I do that?

Vladimír Vondruš

@mosra

hmmm your image->pixels<Color4ub>().prefix<2>({1, image->size()[1], image->size()[0]}); should work 🤔

or even image->pixels<Color4ub>().prefix<2>(1) but there doesn't seem to be such an overload

ah no

if you say prefix<2> it discards the last dimension, taking just the first slice out of it

so you end up with 1, 27, yeah

prefix<n>() takes dimensions off the end, [i] off the start, so you need the [] here

Vladimír Vondruš

@mosra

pixels.transposed<0, 1>().transposed<1, 2>().prefix<2>({image->size()[1], image->size()[0], 1}); would probably work, but ...

pezcode

@pezcode

ah, that makes sense

thanks!

pezcode

@pezcode

~~is it safe to call an instanced test case from another instanced test case? :eyes:~~ ignore that, I need different input files anyway

Vladimír Vondruš

@mosra

should be safe, except that you need to call some verification macro before to register correct function name

Mathew

@lectroMathew

is Quaternion::toMatrix() * Vector3::zAxis() the best way to convert quaternion to directional vector?

Mathew

@lectroMathew

since there's no vector x quaternion overload of operator*

Vladimír Vondruš

@mosra

toMatrix().backward() gives you the Z axis also

Mathew

@lectroMathew

toMatrix spits out Matrix3 so there's no backward()

Visage

@Azvf

I figured it out. Then blit fails when the src rang2di and dst range2di don't match. I split the defaultframebuffer to 2 halves to render so when the width of the defaultframebuffer is an odd number the two parts will have one pixel difference which caused the blit not passing data.

Vladimír Vondruš

@mosra

@lectroMathew ah, in that case just toMatrix()[2] -- for a 3x3 rotation matrix, the three columns are the X Y Z basis vectors

@Azvf oh, glad to hear that :) so the original code caused a GL error or something like that?

Visage

@Azvf

There's no assert or anything, from what i saw just when the 2 rectangles' sizes are not the exactly same, the blit function just won't execute the blit process.

static void Magnum::GL::AbstractFramebuffer::blit(AbstractFramebuffer& source,
AbstractFramebuffer& destination,
const Range2Di& sourceRectangle,
const Range2Di& destinationRectangle,
FramebufferBlitMask mask,
FramebufferBlitFilter filter)

Vladimír Vondruš

@mosra

There's no assert or anything

it'd give an OpenGL error (which is not checked by Magnum by default because it'd be too slow), you only see it if you run with --magnum-gpu-validation on passed on the command line or if you check GL::Renderer::error()

... and the error seems to be this, according to the spec:

GL_INVALID_OPERATION is generated if the value of GL_SAMPLE_BUFFERS for both read and draw buffers is greater than zero and the dimensions of the source and destination rectangles is not identical.

Visage

@Azvf

there's some other info printing at the time, guess I missed that. Noticed now, thank you for the explaination.

Guillaume Jacquemin

@williamjcm

Welp, today I learnt Tweakable doesn't work with hex literals:

Utility::TweakableParser: 0x9F00A5FF has an unexpected suffix, expected u
Utility::Tweakable::update(): change of CORRADE_TWEAKABLE(0x9F00A5FF) in ../../../src/SaveTool/SaveTool_MassViewer.cpp:645 requested a recompile

Vladimír Vondruš

@mosra

huh

it does

but you have to use 0x9F00A5FFu

Guillaume Jacquemin

@williamjcm

Ah.

Vladimír Vondruš

@mosra

i assume it was an unsigned integer before?

there's this restriction where you have to stay at exactly the same type otherwise if you'd save and recompile it could lead to a completely different code (for example due to different function overloads chosen etc)

Guillaume Jacquemin

@williamjcm

i assume it was an unsigned integer before?

Yeah.

An ImU32, to be accurate.

Vladimír Vondruš

@mosra

(thank you @pezcode for the new plugin!)

Guillaume Jacquemin

@williamjcm

Damn, that's quite an improvement.

Vladimír Vondruš

@mosra

it can be even less once openMemory() is a thing

basically, instead of copying everything into some internal representation (like ass imp, like tinygltf) it operates directly on the passed data

so, theoretically, if i would memory-map the file and load it using openMemory() (which only adds a guarantee that the memory doesn't go out of scope so the importer doesn't need to make a copy), then the physical memory usage could be just 370 kB also for the glb case

pezcode

@pezcode

what does ownership transfer mean there?

the memory mapping?

Vladimír Vondruš

@mosra

(i wanted to commit this 3 hours ago but got stuck somewhere else)

it's just about the initial copy not happening in doOpenData()

it took me quite a while to figure out an API that wouldn't require every plugin to implement two or three different variants doOpenData() based on what's passed in

Where communities thrive

People

Repo info

Activity