[SOLVED] Get access to Direct3D textures / RTT

[fonta.romain]

Hello !

 

I'm currently testing how to perform RTT in Unigine (we have huge Geo map computing to draw inside the 3D and must check out that it could be done).

 

At the moment, I could build a specific image (Image classe) and then set it as a texture in the desired material (Material class), but it's not performance friendly.

 

Do you have any advices please ?

 

Thanks !

[ulf.schroeter]

we have huge Geo map computing to draw inside the 3D

 

Could you please describe a little bit more detailled what you exactly want do or achive ? What kind of input data should be rendered to texture, do you have to render to this texture on every frame, can the rendering be done on the GPU or is it mandatory to do it on the CPU, how is the rendered texture used afterwards (mapped on some 3D mesh), ... ?

[fonta.romain]

Hi !

 

Basically, we have a framework in C++ that generate an image of a map (real or not). This map could be panned / zoomed / etc. and is interactive (points, custom data, etc.) using the framework, but the target rendering is only a memory array that is then used in our softwares differently.

 

What we want to achieve is to perform RTT in a 3D scene to reuse all this piece of code if we get a project with Unigine. This texture will be rendered on a plane surface ATM. It is not always useful to render it each frame.

 

Of course we could rebuild the whole system into Unigine, but we prefer to have only one component that we could reuse anywhere easily.

 

Thanks !

[ulf.schroeter]

Sounds like Material::setImageTextureImage() with dynamic texture enabled will than be the only way to transfer your rendered map image from your C++ framework to UNIGINE render texture (there is no direct access to a texture surface from script or C++).

 

Though copying the image data introduces some overhead I wouldn't expect it to be the bottleneck in your overall processing. For sure it would be benefical if your C++ memory layout for image rendering is comaptible with target texture format (e.g. RGB8 or RGBA8) to avoid some intermediate format conversions.

[fonta.romain]

Exactly, and this is what I'm currently doing =)

 

It works, but I have to call after each image update the method you pasted above (even with the dynamic flag set) so it's not performance friendly alas =(

 

We already have as result RGBA8 image so it's already fitting that requirement ;)

 

Thanks for your time =)

[ulf.schroeter]

For this use-case it would be ideal to get direct access to the image memory pointer of the material internal image instance. If this would be possible at least one redundant image copy operation could be avoided.

 

Maybe UNIGINE is willing to provide such functionality for dynamic material texture update from C++. This would require to expose material functionality via C++ interface which is a good idea anyway.

[fonta.romain]

I agree ;)

[manguste]

As we see it, here image copying is definitely not a bottleneck. For example, in DirectX 9, 10 and OpenGL this operation is performed in any case.

[ulf.schroeter]

Of course the final image to texture copy operation is unavoidable, but with current implementation there is a redundant image copy from external image to internal material image. Direct access to internal material image data buffer could avoid one copy operation

[frustum]

We plan to improve C++ API to provide advanced access to materials and textures.

[manguste]

Will be available in the next SDK update.