Could maybe do a depth test in that case, and color based on that. Then use certain colors with your own rules, like green = 1024 map, red = 4K or something. But that’s definitely a more generalized/simple method.
Also, would need to use consistent units probably, so results are not skewed.
Sounds to be like a lot of work for what I would think is little gain. How much faster are your render times for each frame once you have swapped the textures?
jonadb: Good question (seems like you’re always posing good questions ) to be hones I wanted to get on this when I would have finished the speed issue.
The idea with the checker map is cool but that means the user would have to check it (or I need an algorithm that detects checkers o_O ). Basically I just want to create a visual feedback for the needed texture sizes not for the undersampling itself.
denisT: Sometimes I ask myself why we not just send you a simple idea and you hit your secret Make-it-cooler-button. Thank you very much for that great sample there was a lot of new stuff in there but I’m already adapting it for my needs and I love it
Io: You’re speaking in a riddle… kind of, what do you mean? Am I assuming something wrong?
PEN: Sorry, I’m afraid I can’t follow you? What is your point? I mean, I understand your question but I don’t think it’s unnecessary (even if it is, it’s a good practise). Because being able to know which element in the scene would need which size of textures is pretty important. I’ve been into situations where people put lots of efforts into a texture just to see that the texture just needs to be a black square.
i think the right way (and i did this way in some project) is calculate an area that the face can occupy on the screen. after that we need to calculate the UV area in texture space.
and when we know that the face on the screen is 20 sq.pixels, and on the texture is 2000 sq.pixels we see no reason to use this texture because it will be scaled 10 times anyway,
and no one can say that real-time scale works better than pre-calculated.
transPoint = gw.hTransPoint
Doesn’t work with Nitrous :curious:
Denis, does your snippet account for faces that doesn’t point at camera ?
my snippet counts all faces
for nitrous the code has to be changed. it has to use redraw callback as i remember.
Just one more question, denisT you use the gw method which doesn’t take the “real” renderwidth into account is there a better way then in my code to transform the point for the final rendering?