Using GLSL to render individual pixel position on polygon?

[pandoragami]

This is more of yes or no question, I've tried searching around the internet looking for a possible method for setting an individual pixel of whatever color on a polygon face or textured face. Is it possible to do this or am I chasing a red herring?

[CuteAlien]

Not my speciality, so take what I say with a grain of salt.

You can set things with the precision of texture-pixels (as you can write into textures). And you could also calculate if you are at certain position on the polygon in the pixelshader and then do something special when that pixel is rendered - but that's likely a very bad idea. You don't want special conditions like that in the pixel-shader (very slow), so that's fine for applying general modifications (some kind of sinus-wave over the whole texture for example) but not for modifying a single pixel. In most cases it's probably better to have a small polygon if you only want to change minor places. Or if you change your whole texture then write the changes in the texture (but that's also slow).

Maybe we have better ideas when you describe what exactly you need it for.

There's also one thing which makes the questions a little complicated. Your polygons don't have single pixels. Only your screen has that. A polygon close up can take up all pixels on your screen, while the same polygon far away needs only a single pixel. So it's not quite clear what "a pixel on a polygon" would actually mean.

[pandoragami]

Not my speciality, so take what I say with a grain of salt.

You can set things with the precision of texture-pixels (as you can write into textures). And you could also calculate if you are at certain position on the polygon in the pixelshader and then do something special when that pixel is rendered - but that's likely a very bad idea. You don't want special conditions like that in the pixel-shader (very slow), so that's fine for applying general modifications (some kind of sinus-wave over the whole texture for example) but not for modifying a single pixel. In most cases it's probably better to have a small polygon if you only want to change minor places. Or if you change your whole texture then write the changes in the texture (but that's also slow).

Maybe we have better ideas when you describe what exactly you need it for.

Well like I said, to draw pixels onto a polygon, but if it's too slow I guess I wouldn't be interested in going this route. Overall it's more about experimenting rather than some practical use. I don't have anything specific in mind. if you have other methods feel free to mention them I'll do my research from there.

[CuteAlien]

OK, without more specific information - just draw into the texture that's on the polyon. It's not possible to say in general that this is slow or fast. If you mean draw like - a person draws with the mouse - then it's fast enough.

[pandoragami]

OK, without more specific information - just draw into the texture that's on the polyon. It's not possible to say in general that this is slow or fast. If you mean draw like - a person draws with the mouse - then it's fast enough.

That would be around 1/10 of a second scale with GLSL onto a texture, not in the millisecond scale? Like lets pretend you have 640x480 bmp on the face of a polygon, would that be in the range of a few seconds to render?

[CuteAlien]

Sorry, you are just not giving enough details to give us a clue what you try to do. Seconds... you can do build whole worlds when you have seconds to spend :-)

[pandoragami]

Sorry, you are just not giving enough details to give us a clue what you try to do. Seconds... you can do build whole worlds when you have seconds to spend

I want to make a program that simulates graffiti murals (Jet Grind Radio type gaming), something that allows real-time spraying of random noise patterns onto a texture surface, like a brick wall texture. But you know sometimes spray cans can spray fine lines. I hope I'm not breaking any laws doing this, lol.

[Cube_]

seconds?
in 6 seconds I could (following the assumption that I can run 16 threads, which shouldn't be an issue) generate 47,185,920 triangles using my current allocator, these are all fully textured and dynamically lit (that would take 6336 megabytes of ram and probably melt my computer but ignoring rendering restraints I could generate that data in that time).

Rendering a small bitmap on a simple 3D object would be very fast unless you're doing something very very wrong, even if you allow editing it. (given that I can do realtime texture painting of 2048x2048 ARGB textures on objects of hundreds of thousands of triangles without too much trouble... really, it should be pretty trivial).


As for how to edit a texture in irrlicht, not sure (that's something I have considered for my game but won't implement any time soon and as such I haven't looked into it).

[CuteAlien]

Speed is not going to be the problem for this. But it's not quite trivial. Unfortunately no time right now to explain longer - but finding the positions on the textures will be a little math. Deciding how thick to spray can be a little complicated. And deciding how to handle painting on textures which are used in many places is also a thing to think about (using a second texture on top of the first one is the easiest solution, but will get more tricky if you need the second texture already for other stuff. And can again involve some math to figure out some uv's at runtime).

[pandoragami]

Speed is not going to be the problem for this. But it's not quite trivial. Unfortunately no time right now to explain longer - but finding the positions on the textures will be a little math. Deciding how thick to spray can be a little complicated. And deciding how to handle painting on textures which are used in many places is also a thing to think about (using a second texture on top of the first one is the easiest solution, but will get more tricky if you need the second texture already for other stuff. And can again involve some math to figure out some uv's at runtime).

Thanks, that does give me some ideas which I can at least go on, I can do the research myself, it's just the feasibility and getting a good opinion that gives me a belief that this might work.

@aaammmsterdddam I thought Irrlicht was single threaded, how can you possibly use 16?

[Cube_]

Irrlicht itself is single threaded, however some methods can be called from multiple threads in a thread safe manner (however all the scene node allocation is done in the main irrlicht thread as I was advised about it causing memory corruption if I were to do it in another thread)
creating vertices, indices, IMeshBuffers and IAnimatedMeshes seems to work fine with multithreading. (note: just because it seems to work fine on my end doesn't mean it's a good idea, it just means I haven't found any problems in my test application yet)

[mongoose7]

You can't MT creation of mesh buffers if they have unique materials, because loading textures results in a call to the GPU. You can't MT creation of nodes because they are linked, either to the SM or to a parent node you specify.

[pandoragami]

You can't MT creation of mesh buffers if they have unique materials, because loading textures results in a call to the GPU. You can't MT creation of nodes because they are linked, either to the SM or to a parent node you specify.

What's SM? Just for sake of reference.

[mongoose7]

Scene manager.