Horde3D

Next-Generation Graphics Engine
It is currently 14.11.2024, 18:34

View unanswered posts | View active topics


Board index » Horde3D Usage » General Discussion

All times are UTC + 1 hour




Post new topic Reply to topic  Page 1 of 1
  [ 9 posts ] 
  Print view Previous topic | Next topic 
Author Message
phoenix64
 Post subject: Texture access
PostPosted: 26.08.2008, 20:04 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
It might be handy in some cases to have direct access to the texture data (in my case I wanted to plant some trees onto a terrain and needed the heightmap for that). So this might be good:

Code:
Index: Horde3D/Source/Horde3DEngine/egTextures.cpp
===================================================================
--- Horde3D/Source/Horde3DEngine/egTextures.cpp   (Revision 46)
+++ Horde3D/Source/Horde3DEngine/egTextures.cpp   (Arbeitskopie)
@@ -280,9 +280,20 @@
    }

 

    return false;

+}
+

+const void *Texture2DResource::getData( int param )
+{
+   if( param == TextureResParams::PixelData )

+   {
+      if( _texObject == 0 ) return false;
+      
+      return downloadImageData();
+   }
+   
+   return 0;
 }

 

-

 float *Texture2DResource::downloadImageData()

 {

    int width, height;

Index: Horde3D/Source/Horde3DEngine/egTextures.h
===================================================================
--- Horde3D/Source/Horde3DEngine/egTextures.h   (Revision 46)
+++ Horde3D/Source/Horde3DEngine/egTextures.h   (Arbeitskopie)
@@ -85,7 +85,8 @@
    void initDefault();

    void release();

    bool load( const char *data, int size );

-   bool updateData( int param, const void *data, int size );

+   bool updateData( int param, const void *data, int size );
+   const void *getData( int param );

    float *downloadImageData();

 

    int getParami( int param );

Index: Horde3D/Bindings/C++/Horde3D.h
===================================================================
--- Horde3D/Bindings/C++/Horde3D.h   (Revision 46)
+++ Horde3D/Bindings/C++/Horde3D.h   (Arbeitskopie)
@@ -1019,7 +1019,13 @@
         format (uint, float, ..) of the pointer see the ResourceData description.

 

         *Important Note: The pointer is const and allows only read access to the data. Do never try to modify the

-        data of the pointer since that can corrupt the engine's internal states!*

+        data of the pointer since that can corrupt the engine's internal states!*
+
+        Notes on available ResourceData parameters:

+      - Texture2DResData::PixelData
+         Returns the image data of a Texture2D resource. Note that you have to free it manually in this case!
+         The returned pointer points to an array of float, where one pixel is represented by 4 floats in RGBA
+         format.

       

       Parameters:

          res      - handle to the resource to be accessed



Well, I know this is quite hacky, but I actually didn't find a way which fitted better into the concept, storing the data with the texture would have caused much memory overhead again.

Also there are quite some EOL-changes in this diff, that's because Horde3D svn doesn't use svn:eol-style=native (can anybody fix this?), and I'm on Linux. Of course those changes get lost at the moment I type this text into the web browser :p

EDIT: Fixed broken diff. Never simply paste out of a terminal window -.-
Top
 Profile  
Reply with quote  
marciano
 Post subject: Re: Texture access
PostPosted: 27.08.2008, 18:54 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
Thanks for the patch.

We were thinking about that problem some time ago and thought that it could be practical to add some resource creation hint flags that specify where resource data should be stored (RAM, VRAM or both).
Top
 Profile  
Reply with quote  
phoenix64
 Post subject: Re: Texture access
PostPosted: 28.08.2008, 15:57 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
I wouldn't actually make that not only a creation flag but rather a parameter which would be changeable at runtime (this actually isn't any problem at all). I'll later try to make a better patch for this and then show you how I mean it.
Top
 Profile  
Reply with quote  
Volker
 Post subject: Re: Texture access
PostPosted: 28.08.2008, 18:19 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
Should be possible to realize by using setResourceParami on the texture resource. It may be suggestive to add an additional variable that hold the image data in system memory if it was specified by the appropriate flag. This way you also don't have to worry about releasing the memory. If you don't specify a texture be kept in system memory you just can't get it's data. If you specify both, system memory and video memory you can get it and render it and if you just keep it in system memory, you can use it e.g. for a heightmap data, that you don't use for rendering.
It might be also usefull to add an easy method of uploading partial areas or the whole image. This way the texture can be changed directly in the system memory copy and you don't have to care about uploading and downloading to/from video memory when you want to manipulate texture data on the cpu. As an example the pointer to the texture data in system memory can be passed to a video capture library that can directly copy the video data to that memory block. Or is there any possibility to directly copy data into video memory? I don't have much experience with things like FBOs.
Top
 Profile  
Reply with quote  
phoenix64
 Post subject: Re: Texture access
PostPosted: 29.08.2008, 12:58 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
Quote:
hould be possible to realize by using setResourceParami on the texture resource. It may be suggestive to add an additional variable that hold the image data in system memory if it was specified by the appropriate flag. This way you also don't have to worry about releasing the memory.

That's exactly what I thought of.

I wouldn't create RAM-only textures though, usually you need all textures in the shaders as well. If they are needed to only be in RAM because of performance reasons, people should include 3rd party libraries. Because these textures don't actually have to do anything with the graphics directly, I'd consider this bloat, at least in Horde3D.

Quote:
It might be also usefull to add an easy method of uploading partial areas or the whole image. This way the texture can be changed directly in the system memory copy and you don't have to care about uploading and downloading to/from video memory when you want to manipulate texture data on the cpu.

Is this actually possible with OpenGL?
Top
 Profile  
Reply with quote  
Volker
 Post subject: Re: Texture access
PostPosted: 29.08.2008, 14:14 
Offline
Tool Developer

Joined: 13.11.2007, 11:07
Posts: 1150
Location: Germany
phoenix64 wrote:
Quote:
It might be also usefull to add an easy method of uploading partial areas or the whole image. This way the texture can be changed directly in the system memory copy and you don't have to care about uploading and downloading to/from video memory when you want to manipulate texture data on the cpu.

Is this actually possible with OpenGL?

I thought glTexSubImage2D can be used this way.
Top
 Profile  
Reply with quote  
phoenix64
 Post subject: Re: Texture access
PostPosted: 29.08.2008, 14:20 
Offline

Joined: 15.06.2008, 11:21
Posts: 166
Location: Germany
Ah, ok, looks good. So atm we need like two functions, updateTexture(texture) and updateTextureRect(texture, x, y, width, height)?
And the integer parameter which sets whether the image is stored in RAM? Shoud RTT rendertargets be put into RAM automatically when needed? (usually you wouldn't put them into RAM anyways, the only thing why you would want this is to read in the data!)
Top
 Profile  
Reply with quote  
swiftcoder
 Post subject: Re: Texture access
PostPosted: 29.08.2008, 15:29 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
Volker wrote:
phoenix64 wrote:
Quote:
It might be also usefull to add an easy method of uploading partial areas or the whole image. This way the texture can be changed directly in the system memory copy and you don't have to care about uploading and downloading to/from video memory when you want to manipulate texture data on the cpu.
Is this actually possible with OpenGL?
I thought glTexSubImage2D can be used this way.
It can in theory, but you are going to bring the pipeline to a screaming halt. It wont stall as badly if you can read it back the following frame instead (copy the texture on the GPU, and then read it next frame).

_________________
Tristam MacDonald - [swiftcoding]
Top
 Profile  
Reply with quote  
marciano
 Post subject: Re: Texture access
PostPosted: 29.08.2008, 22:11 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
phoenix64 wrote:
Shoud RTT rendertargets be put into RAM automatically when needed? (usually you wouldn't put them into RAM anyways, the only thing why you would want this is to read in the data!)

We already have a function to read back render target data but that's only meant fo debugging (the horde editor can show intermediary pipeline results). Currently this function copies the data to user allocated memory.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 1
  [ 9 posts ] 

Board index » Horde3D Usage » General Discussion

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 16 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group