About using "https://www.jpct.net/doc/com/threed/jpct/IRenderHook.html", how can I access the Object data in order to manipulate it to the GPU?

For example, if I wanted to call GL11.glDrawElementsInstanced(GLenum,GLsizei,GLenum,indices, GLsizei);, how could I access the indices? and at which moment? beforeRendering()?

Or on the setObject(), should I use a VertexController to send the data to the GPU?

This way, it will allow performant operations such as:

- Position change
- Orientation change
- Scaling change
- Visibility change
- And count change

whereas using a mesh and change it via GenericVertexController, wouldn't work as fast as using Instancing, and inscresing or descresing elements in scene, because the control and iteration will be done in the CPU side, which we all know the GPU is way better for such things.

The main goal is clearly reducing the calls to the GPU

Quote from: EgonOlsen on January 29, 2021, 09:03:41 AM
I don't see the point in that approach. It would be the same thing as using multiple objects in the first place or wouldn't it?

Maybe you didn't get my idea.

The concept would be to use references of matrix data (position, rotation and scale), which is the logic side of the system, and then a Global List which is a reference for a single Mesh, that will be sent to the GPU via glDrawArraysInstanced, where the data from the logical objects will be sent via shader, that is predefined, withou the user needing to mess with it.

Something like this:

- InstancedManager (ObjectContainer3D), that receives a mesh reference
- then a user can create as many objects (InstancedObject3D) as he wants (which are objects that only contains matrix data, and maybe some texture related data, alpha, displacement, etc)  which will be sent to a prebuilt shader.

of course this will yield out way better results, no doubt.

and this will make things easy to use and control.

Getting back on this topic, the batching example on the wiki didn't work as expected, or even worked at all with relevant results.

So my question is: is there any way of overriding any part so that I could try and implement a simple Batch Use case, mostly for sprites and static objects?
I'm working on a scene that has a lot of concentrated objects all at once (particles) which is dropping the frame rate considerably, and using Batch Instancing would increase it drastically leaving me more room for the rest.

My main idea, would be to simply its usage, something like an extended Object3D, which is a container for children Objects (which are not present in the world) that would be batched all at once

ObjectContainer3D
- InstancedObject3D List
- Refresh();

and after calling the refresh method, the Data will be sent to the GPU.

I think that could improve drastically the performance and usabilty of the framework

It was way better. Iterating millions of times had its cost

Yep, it worked, changing the channel order worked.

But, is there any way to set the image format to that order from the start, without having to iterate every pixel and rearrange it to the RGBA order? do you know any way besides using image type that could set the RGBA order correcly from the start?

regards

here is a clearer example:

Original image:


Resulting Image when using ARGB:


Resulting Image when using ABGR: Note that this one is the format the comes from ImageIO.read

Yes, and it doesn't look like it, mainly because it's not only channel flipping but channel mixing,

i've tried this: img = new BufferedImage(w, h, BufferedImage.TYPE_INT_ARGB);

and this is the result:



the weird part is that I'm not using alpha channel, the original resulting image doesn't have any kind of transparency

Hello,

I'm using the method Texture.overrideTexelData, but it seems that its data is not being used correctly in the texture.
my example below shows the problem with it.

Im using this simples code to change texture data on the fly:


public void update() {
BufferedImage img = new BufferedImage(w, h, BufferedImage.TYPE_4BYTE_ABGR);
int size = w * h * 4;
ByteBuffer buffer = ByteBuffer.allocateDirect(size);
buffer.order(ByteOrder.LITTLE_ENDIAN);

<Draw on Image> -> img.getGraphics().drawImage(spr, 0, 0, null);

DataBuffer dataBuffer = img.getRaster().getDataBuffer();
byte[] pixelData = ((DataBufferByte) dataBuffer).getData();
buffer.put(pixelData);
tex.overrideTexelData(buffer);
}


Results:

Original Image:


Drawn Image:


so, it sems that the color params are being swapped when uploading them to the buffer somewhere

My main concern is about reducing overhead on low end computers in game development.

But TBF, the reason I was looking for an improvement on what I have, is mainly because I tend to use a lot of fixed and static objects that are clones, differing only on their position, but sharing not only mesh and texture data as well, and I am already using the shareCompiledData and shareTextureData, but I was having some bottlenecks when having 2000+ more objects on the same scene, and even inside the frustum.

But when it comes to shaders that is not my best preference, because everytime I need to add a shader to an already existing shader, I need to combine them and check if the code still remains valid

Regards,
Jakes

That is not batching the objects per se, rather just reusing the same mesh data in order to reduce memory usage.
What I'm talking about is batching objects (not meshes) in a single call to the GPU in order to reduce callback bottleneck caused by multiple calls to the pipeline.

I've seen this:

https://www.jpct.net/wiki/index.php?title=Instance_Batch_Rendering

but this is not bundled in the JPCT API, so I have some concerns regading Desktop version, and there are no examples on how to use and documentation about understanding it.

does anyone know if this will work with the Desktop vesion and requires a shader explicitly for this?

Hello,

I was wondering if there is a prebuilt method for batching up sprites to the GPU instead of sending multiple objects individualy, as it increases a lot the performance when using particle systems or packs of elements sharing same mesh,

thanks,
Jakes

Yeah, I know that what I was expecting was the issue with the painters algorithm, and that was what I was expecting, because even if I wanted to used the discard method on a shader, the plane in the back would still overlap with the front plane, so thats why I was asking if there is a way to force those planes to write to the buffer, even if the clipping were to happen, and then I would sort them myself or even use a shader to discard the pixels I dont want to be written to the zbuffer. in that case the rendering would appear fine.

You saíd that they dont write to zbuffer, is that it? is there any reason why? aside from not writing the alpha values of course, they should write their values as being a normal plane, no?

Both are transparent planes one in front of the other regarding the camera position.
the order would be:

Red Circle Plane
      ⬆️
Blue Circle Plane
      ⬆️
Camera