Texture Streaming Refactor proposal (w/ SLIDES)

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)

Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 2:51 am

I originally wanted to delay this texture refactor for after 2.1

But as time goes on, and users make it more visible... the current Texture system is showing its limits:
  • Poor MSAA support.
  • No async streaming.
  • Takes forever to upload, often causing stalls.
  • Wastes a lot of memory.
  • Hlms forces textures to be loaded, consuming a lot of GPU memory.
  • No residency support, thus we reach out of memory conditions too early (specially bad for Editors and big projects)
  • Clunky interface (HardwarePixelBuffer, RenderTarget, Textures... they're interrelated yet different, and if a variable is required but you don't hold the pointer... it gets difficult to grab it).
  • Hard to prepare for Vulkan/DX12.
  • Can't render to 2D array slices, nor 3D slices.

So a new system is needed. I am uploading my design plan. I tried to catch every single problem I could foresee. Feedback would be appreciated:

There is a gotcha: this new system will replace the old one. There won't be a v1::Texture and v1::RenderTarget because it would be very difficult to support both interfaces at the same time. That means it will be a breaking change (and a big one).
Fortunately most of you (myself included) only use textures superficially, i.e. ask Ogre to load it, then set the material.
Creating RenderTextures via code will be affected as well, but I'm crossing my fingers this should be relatively easy to port (given that the RTT code should become simpler).
The ones I suspect will be affected the most is those who lock textures for writing/reading, as these interfaces and their behavior could change drastically. Those who relied on misc stuff like blitFramebuffer to scale will be affected the most (if you want to "blit" and not just copy, use a pass_quad!)

Any thoughts?
You think it will be too groundbreaking? Perhaps someone figures a clean way to phase the old system for the new one without deleting it?

Thanks
Cheers

For this message the author dark_sylinc has received 2 kudos
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby xrgo » Wed Sep 07, 2016 3:16 am

Sounds awesome, I personally don't care if I have to spend a few days refactoring my engine for a new system because the old one was deleted, it worth it if we get all those features/fixes you mentioned =). so my vote is HELL YEAH
Its one more step to the future!!

I love you man =) keep it up
xrgo
Gnoll
 
Posts: 693
Kudos: 47
Joined: 06 Jul 2013
Location: Chile

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 3:51 am

I forgot to mention this won't happen overnight. Probably the changes are going to require a few months, and I won't start right away. This is basically feedback gathering.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby GlowingPotato » Wed Sep 07, 2016 4:05 am

Is it Christmas already ? :lol:

I read the PDF twice. As you may know, I'm not a programmer, so my feedback is very limited regarding some of the technical details.
I like your idea of displaying a 4x4 blank texture and/or loading a texture from the last mipmap first. Same thing happens with unreal.

Maybe you can find some interesting information here ->Unreal texture Streaming, some of the stuff you described sounds similar to unreal.

You mentioned three modes in Explicit Residency, the ideia is to choose one for development ? On Sys. RAM sounds like a good strategy, larger projects would greatly benefit from 64bit compilation. Otherwise, reading from disk can cause long times with a blank texture (or the 64x64). I don't see a problem here, every major game is shipping x64 these days.

For the naming convention, if I may suggest (remember, I'm no programmer), High priority and Low priority is very self explanatory.

For the rest, well... I can't really say much, others will provide a much more useful feedback than me. :roll:

We (me and Aymar) will be happy to test the shit out of this when the test phase starts. It will greatly impact our project on a very good way.

Amazing stuff Matías

EDIT: Ohhh I get now, you actually need all three residency modes. Neat
User avatar
GlowingPotato
Goblin
 
Posts: 211
Kudos: 10
Joined: 08 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 4:54 am

GlowingPotato wrote:Maybe you can find some interesting information here ->Unreal texture Streaming, some of the stuff you described sounds similar to unreal.

Interesting. It's worth checking out to see if I missed a use case.

GlowingPotato wrote:You mentioned three modes in Explicit Residency, the ideia is to choose one for development ? On Sys. RAM sounds like a good strategy, larger projects would greatly benefit from 64bit compilation. Otherwise, reading from disk can cause long times with a blank texture (or the 64x64). I don't see a problem here, every major game is shipping x64 these days.

What I'm foreseeing is that:
  • Memory on iOS is scarce, but its flash memory is relatively fast. So you'll probably want to have mostly no sys. ram backup, and rather always stream from disk
  • In x64 you have lots of memory available, so you probably want to use Sys. RAM.
  • Even if you have lots of memory on x64; profiling may reveal you use too much. Thus you'll have to prioritize (i.e. main character's textures = Sys RAM; some rare texture = stream from disk). You may even want to change it dynamically. For example if a texture is only used in a particular region; set it to Sys RAM while you're in the vecinity, but change it to stream from disk when you're far away (or monitor RAM consumption, and begin setting to progressively set to stream from disk)
  • The OS does also cache disk reads into RAM, thus making stream from disk really fast the second time. I normally don't like leaving stuff like that to the OS, but it's worth noting stream from disk does not means it's immediately ultra slow (at least on Windows, Linux & OS X) as long as the OS still has a cache.
  • Editors may have to load A LOT of textures. Most of them probably won't even be used at all. The editor may choose which textures are high priority and thus have Sys. RAM, and the rest stream from disk.

GlowingPotato wrote:For the naming convention, if I may suggest (remember, I'm no programmer), High priority and Low priority is very self explanatory.

The problem is that a low number is high priority while a high number means low priority. So... when I say "set it to high" did I mean to use a high value (low priority) or a low value (high priority)?

GlowingPotato wrote:For the rest, well... I can't really say much, others will provide a much more useful feedback than me. :roll:

We (me and Aymar) will be happy to test the shit out of this when the test phase starts. It will greatly impact our project on a very good way.

Amazing stuff Matías

Thanks. :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 5:01 am

GlowingPotato wrote:EDIT: Ohhh I get now, you actually need all three residency modes. Neat

The texture may be in one of the three states (actual implementation may have more to account for transitions).

The important part is you need to tell Ogre what to do when Ogre decides the texture needs to be swapped out:
  1. Should we destroy it and load it again from disk the next time?
  2. Should we keep a duplicate on sys. RAM at all times and destroy the GPU version? (consumes twice as much memory: one copy in VRAM, one copy in RAM)
  3. or should we transfer from GPU to sys. RAM then destroy it? (consumes more bandwidth to perform the download)

Having a clone at all times seems useless considering today's PCI-e bandwidth. But I need to plan for people who is actually saturating it. Besides, integrated GPUs could benefit from avoiding to download the data from GPU (which wastes precious system bandwidth as the GPU just "pretends" a portion of system RAM is like dedicated RAM)).
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby Daixiwen » Wed Sep 07, 2016 7:33 am

As an end user I also vote for the groudbreaking change. With all the other modifications in 2.1 I think now is the best time to make API changes. I'm not qualified enough to make any suggestions but I like the idea of the blank texture while it is loading, and this streaming process with the ability to page out textures will make it a lot easier for open world games where we don't have to worry so much (well, not as much ;) ) about hitting the GPU memory limit.

And yes I don't think we say it enough, kudoes for all the good work you are doing for Ogre Matías! It really is amazing
Hardware, n.: part of the computer you can kick
User avatar
Daixiwen
Greenskin
 
Posts: 101
Kudos: 13
Joined: 08 Feb 2013
Location: Oslo

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby spookyboo » Wed Sep 07, 2016 8:08 am

As usual you have given it a lot of thought. I only have one comment: I assume you are more in control of the texture streams, but without any proper measurement tool I guess it becomes difficult to optimize it, which leads to a lot of trial and error. Would be nice if it was possible to (optionally) compile Ogre with a type of build-in monitoring tool (imgui?)
User avatar
spookyboo
Silver Sponsor
Silver Sponsor
 
Posts: 1112
Kudos: 128
Joined: 06 Jul 2004

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby Zonder » Wed Sep 07, 2016 3:16 pm

I really think a poll should be made on adding to the 2.1 version since it is such a breaking change. In my eyes it should be done for 2.2 it would be nice to see 2.1 finalized and released. Remembering there has been no official release of ogre in nearly 3 years.

Negativity away :roll: surface what you describe has been on my mind for a while on how it should work. But I am going to read through the doc tomorrow and give any feedback I think is relevant :)
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.dreamwalkerblog.com
User avatar
Zonder
Gargoyle
 
Posts: 1056
Kudos: 38
Joined: 04 Aug 2008
Location: Manchester - England

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby devxkh » Wed Sep 07, 2016 5:08 pm

if it means: we can load items on demand and don't need to load/intialize all materials at start

... do it ... just do it! do it yesterday.
User avatar
devxkh
Halfling
 
Posts: 60
Kudos: 4
Joined: 02 Aug 2016
Location: Germany

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 6:45 pm

I read the Unreal stuff. Internally it works quite differently from what I have in mind but the goal is more or less the same. I noticed a couple major differences:
  • Unreal supports dropping mips at very fine granularity. e.g. In a 2048x2048 texture, drop mip 0 and go to 1024x1024. Then 512x512 and so on. My plan is not so granular. Either 64x64 or 2048x2048. The reason is that we group textures into arrays to avoid unnecessary state changes. If the texture is in a 2048x2048 array, we can't just drop one mip level. We would have to migrate the texture to a different array. While GPU this is just a GPU->GPU memcpy, CPU side we'd have to rebuild the texture hashes and possibly recompile a new shader, which is sloooooow. Perhaps is doable, but such fine granular control is not the goal. Why 64x64? because it offers quality decent enough to tell what I'm looking at while the full res is loading, and is small (one RGBA8888 is just 16kb). 2048 slices of these 64x64 is 32MB, and would cover almost every texture needed (note we also need more arrays of 64x64 for the different compressed formats). If they were 128x128, that would require 128MB, which is not acceptable (note: we don't have to specifically allocate 2048 64x64 textures, but you get the point).
  • Unreal seems to have a very detailed heuristic to compute the mip level based on distance. I don't know how accurate that is, but mine is definitely planning to be more simple and not pixel-coverage accurate. Since I am only aiming to 64x64 or everything, it's not that big deal.
  • Unreal is trying to aggressively fit a given memory budget. This is a nice idea, though given our all-or-64x64-or-nothing approach sticking to a budget sounds harder (though not impossible... i.e. we should be able to load a 2048x2048 as a 1024x1024 texture instead if we're overbudget. It's just that Ogre's perf. could be hurt if we're constantly switching between mips). Our current goals is prevent from blowing up memory consumption (in Unreal terms... getting WAY overbudget) and prevent stalls (as well as other technical issues).

spookyboo wrote:As usual you have given it a lot of thought. I only have one comment: I assume you are more in control of the texture streams, but without any proper measurement tool I guess it becomes difficult to optimize it, which leads to a lot of trial and error.

That is an excellent point I didn't consider!
We certainly will need more measurement tools. Unreal is very handy on ideas for that.

spookyboo wrote:Would be nice if it was possible to (optionally) compile Ogre with a type of build-in monitoring tool (imgui?)

For many months I have my eyes set on Remotery. I like the webserver approach because it's much more beneficial for iOS and Android targets.
Remotery doesn't support custom values yet, though I've been told such functionality may appear in around 3 months. Which is totally fine.

devxkh wrote:if it means: we can load items on demand and don't need to load/intialize all materials at start

... do it ... just do it! do it yesterday.

Materials will load and initialize at start, it's just the textures won't be loaded from disk until they're used; which is what's killing loading times and blowing up memory consumption. Until they're fully loaded the textures will be pointing to dummy 4x4 textures (or a 64x64 one)

Zonder wrote:I really think a poll should be made on adding to the 2.1 version since it is such a breaking change. In my eyes it should be done for 2.2 it would be nice to see 2.1 finalized and released. Remembering there has been no official release of ogre in nearly 3 years.

Negativity away :roll: surface what you describe has been on my mind for a while on how it should work. But I am going to read through the doc tomorrow and give any feedback I think is relevant :)

That is something that annoys me as well. I don't really care about "no official release of ogre in nearly 3 years". It will be done when it's done. But the refactor could certainly grant a "2.2" number... yet I don't want another controversial "stable but not officially stable" release as with what happened with 2.0
I'm not certain how best to handle this.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby GlowingPotato » Wed Sep 07, 2016 8:58 pm

dark_sylinc wrote:I read the Unreal stuff. Internally it works quite differently from what I have in mind but the goal is more or less the same. I noticed a couple major differences:
Unreal supports dropping mips at very fine granularity. e.g. In a 2048x2048 texture, drop mip 0 and go to 1024x1024. Then 512x512 and so on. My plan is not so granular. Either 64x64 or 2048x2048. The reason is that we group textures into arrays to avoid unnecessary state changes. If the texture is in a 2048x2048 array, we can't just drop one mip level. We would have to migrate the texture to a different array. While GPU this is just a GPU->GPU memcpy, CPU side we'd have to rebuild the texture hashes and possibly recompile a new shader, which is sloooooow. Perhaps is doable, but such fine granular control is not the goal. Why 64x64? because it offers quality decent enough to tell what I'm looking at while the full res is loading, and is small (one RGBA8888 is just 16kb). 2048 slices of these 64x64 is 32MB, and would cover almost every texture needed (note we also need more arrays of 64x64 for the different compressed formats). If they were 128x128, that would require 128MB, which is not acceptable (note: we don't have to specifically allocate 2048 64x64 textures, but you get the point).
Unreal seems to have a very detailed heuristic to compute the mip level based on distance. I don't know how accurate that is, but mine is definitely planning to be more simple and not pixel-coverage accurate. Since I am only aiming to 64x64 or everything, it's not that big deal.
Unreal is trying to aggressively fit a given memory budget. This is a nice idea, though given our all-or-64x64-or-nothing approach sticking to a budget sounds harder (though not impossible... i.e. we should be able to load a 2048x2048 as a 1024x1024 texture instead if we're overbudget. It's just that Ogre's perf. could be hurt if we're constantly switching between mips). Our current goals is prevent from blowing up memory consumption (in Unreal terms... getting WAY overbudget) and prevent stalls (as well as other technical issues).


I guess... since unreal needs to compile the game for consoles and smartphones, its tends to be that aggressive in terms of memory consumption.

In my opinion, just preventing stalls, reducing long loading times (looking at you DX11 ¬¬) and avoid disk swapping would be a great start.

Would this system makes easy to hot reload textures ?
User avatar
GlowingPotato
Goblin
 
Posts: 211
Kudos: 10
Joined: 08 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Wed Sep 07, 2016 9:07 pm

GlowingPotato wrote:Would this system makes easy to hot reload textures ?

I don't see why not. Just set the texture to always stream from disk, then force Ogre to unpage it and page it again. It will reload in the background (though it will switch to the 64x64 version while doing that). The 64x64 version will not notice the hot reload though unless we code for that.
It might be possible to keep the full res version while hot reloading the "new" full version but special care would have to be taken (and I'm not sure if implementation details will make it hard or easy).
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby Zonder » Thu Sep 08, 2016 8:21 am

Zonder wrote:I really think a poll should be made on adding to the 2.1 version since it is such a breaking change. In my eyes it should be done for 2.2 it would be nice to see 2.1 finalized and released. Remembering there has been no official release of ogre in nearly 3 years.

Negativity away :roll: surface what you describe has been on my mind for a while on how it should work. But I am going to read through the doc tomorrow and give any feedback I think is relevant :)

That is something that annoys me as well. I don't really care about "no official release of ogre in nearly 3 years". It will be done when it's done. But the refactor could certainly grant a "2.2" number... yet I don't want another controversial "stable but not officially stable" release as with what happened with 2.0
I'm not certain how best to handle this.[/quote]

I wasn't saying that for my benefit it's just I'm aware people expect to see it :roll:.

For me it's more a versioning thing feature xxx is available in version xxx. This been a API breaking change upping the version number is enough.
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.dreamwalkerblog.com

For this message the author Zonder has received kudos
User avatar
Zonder
Gargoyle
 
Posts: 1056
Kudos: 38
Joined: 04 Aug 2008
Location: Manchester - England

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby Zonder » Thu Sep 08, 2016 8:44 am

Just had a read through looks good to me nice work! :D

Just 1 question how are the MIPS textures going to be created, read in / auto generated? (Sorry if I missed that in the PDF)
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.dreamwalkerblog.com
User avatar
Zonder
Gargoyle
 
Posts: 1056
Kudos: 38
Joined: 04 Aug 2008
Location: Manchester - England

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby GlowingPotato » Thu Sep 08, 2016 12:53 pm

Zonder wrote:Just had a read through looks good to me nice work! :D

Just 1 question how are the MIPS textures going to be created, read in / auto generated? (Sorry if I missed that in the PDF)


Good point on mipmap generation.


As an artist, I would like to drop a few considerations when working with textures. Since this is a start of a planning phase, maybe we can work out some issues and makes future work easy.
Sunset Rangers is the third project our studio is working using Ogre. The last was Damned, it was kinda a big project too, but Sunset surpass it in many forms of scale.

My daily concern is Vram budget. We are always trying to re-use texture in many ways possible. For this, we kinda adopted the material workflow.
We produce many tillable materials, like metals, woods, stones, plasters, etc. Then, for variation, we use details maps with dirt, rust, craks, and anything that can be used to break the tilling effect and make variations. So normally, an asset is composed of multiple materials.

We primarily work with TGA textures, then a python script is in charge to reduce the texture sizes to two resolution targets and transform it to .DDS using custom filtering for mipmaps. So we end it with a high resolution texture, a medium and a low resolution. Those can be selected on the settings menu of our game, and the game must be restarted in order to the change to take effect.

Maybe shipping the game with those textures in multiple resolution is not the optimized way of doing it (disk space, texture management...), because we already have those resolutions in the mips of the high resolution texture. It would be very nice if we could just simple drop the higher mips when selecting medium or low res. textures.

The same script that resize textures, is in charge of channel packing. Today, we pack together booth roughness and metallic channel in DXT1 format. Normals have its own BC5 and color maps have a DXT1 and DXT5 when alpha needs to be used.
Now, we are considering packing roughness, metallic and normal map on a single texture map (Yeah, quality will be lost, but Vram budget comes first).

When creating new content for Sunset Rangers, we primarily use our game editor to preview the asset, like size, Uvs and textures. But to have true felling about how it will behave on the game world, we must insert it in the game and execute the game. So, for every change on the asset texture, we must open the game, and that takes time. A hot reload would greatly boost production time here.


I'm writing this because those are my daily concerns. Maybe, some of this only apply to us, maybe not. I think having another point of view (art point of view) may help to plan this new feature.
It would be very cool if others share their texture/texturing pipeline so we can help Matías to develop something that can be truly used to solve today's problems for us all.
Last edited by GlowingPotato on Thu Sep 08, 2016 1:47 pm, edited 1 time in total.
User avatar
GlowingPotato
Goblin
 
Posts: 211
Kudos: 10
Joined: 08 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby aymar » Thu Sep 08, 2016 1:44 pm

Hey,

This all sounds great! We'd love to have texture streaming under Ogre's hood.

Some thoughts as feedback:
- I agree about the versioning stuff, texture streaming sounds like a feature that should up the version by one: Ogre 2.2.
- Regarding the naming convension for priority I have two points to add:
1. High Priority and Low Priority are strong expressions, maybe we should consider having them, one possibility could be the user inputs priority and then we invert it to obtain rank (e.g. priority 255 means rank 0, priority 0 means rank 255), or even we could allow setting priority via enum class and hide the rank numbers from the user (e.g. setPriority(HighestPriority/HighPriority/...) ).
2. If using high/low priority won't do, maybe we could call rank the opposite of priority, e.g. volatility (0 means non-volatile, always resident).
- I'm thinking about the Low Level Materials, would this affect them and their textures in any way? We use low levels in multiple situations: Compositor for post fx, Particles, custom Billboards.

Congratulations for the iniciative Matías, this is great news, the community will benefit greatly from this.
aymar
Greenskin
 
Posts: 124
Kudos: 16
Joined: 12 Jun 2015

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby frostbyte » Thu Sep 08, 2016 4:22 pm

wrote a long post, now is gone...sign to make it short...
me like , good plan, but... but..gles renderer,lighter mobile pbs, custom HLMS tutorial is of more important prior( showStopper feature )

as someone wishing to upgrade from 1.x at some point...this "API breaking" refactoring should be in a branch( like the pso brance ) and merged into 2.2 when done...
so 1.x "upgraders" can have easier time using 2.1 main branch...as not much of 1.x api would be left after this...also, not everybody is in dire need for this..
i think people forgot a bit about what is the purpose of versioning...isn't part of it is to preserve API state between big changes?

your delecation to ogre is inspiring...
thanks, cheerZ (-:
For this message the author frostbyte has received 64K kudos
frostbyte
Gnoll
 
Posts: 687
Kudos: 42
Joined: 31 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby dark_sylinc » Thu Sep 08, 2016 7:43 pm

@GlowinPotato
Thanks a lot for your feedback! It's very useful!

Regarding your workflow:
  • Things like what you mention about converting TGA to DXT1/BC5 etc fall out of the scope of this refactor. And often need to be customized. However a lot of people will probably have the same needs, so after the refactor we could chat and see if you could contribute your scripts and conversion tools and we facilitate integration with them in Ogre. Since I'm guessing you're using some propietary tools (i.e. not all DDS converters are open source) we may have to provide a binary download option instead. Tools are definitely something we're looking forward for the future of Ogre. At least everyone should be hinted to use the same conventions. i.e. Targetting multiple platforms means we need to convert to DDS, ETC, PVRTC, ASTC and keep things consistent and for quick iteration. Basically, what Unity does.
  • Loading mipmaps: I forgot to mention that in order to start by loading from the 64x64 mipmaps and below, then load the rest; we need the DDS texture to have the mipmaps already computated (otherwise we would have to load the full res to compute the mips... which beats the point). I also plan on doing a JSON file to specify some texture data (i.e. if you want a specific file to be loaded in a specific format, to be aliased to a different name, etc)
  • Loading mipmaps: You made me realize I should definitely watch out more carefully about selecting up to which mip you want to load (i.e. quality settings). Thank you.
  • Hot Reloading: I've realized it's more important than I thought. Needs a little thought (i.e. what I had in mind would not work if the texture suddenly changes resolution). We can fix this.

aymar wrote:- Regarding the naming convension for priority I have two points to add:
1. High Priority and Low Priority are strong expressions, maybe we should consider having them, one possibility could be the user inputs priority and then we invert it to obtain rank (e.g. priority 255 means rank 0, priority 0 means rank 255), or even we could allow setting priority via enum class and hide the rank numbers from the user (e.g. setPriority(HighestPriority/HighPriority/...) ).
2. If using high/low priority won't do, maybe we could call rank the opposite of priority, e.g. volatility (0 means non-volatile, always resident).

I like volatility! Thanks!!!
About priority ranks... it may end up being a floating point. And values could be arbitrary so assuming you can subtract from 255 would be problematic. Basically the distance to camera gets multiplied by the volatility value; determining the total priority.
This means what value is best might depend on the scale you're on (centimeters vs meters vs miles) and how tight the thresholds you want.

- I'm thinking about the Low Level Materials, would this affect them and their textures in any way? We use low levels in multiple situations: Compositor for post fx, Particles, custom Billboards.

Low level materials have an Hlms and an HlmsDatablock under the hood, so they will be covered as well.

frostbyte wrote:wrote a long post, now is gone...sign to make it short...
me like , good plan, but... but..gles renderer,lighter mobile pbs, custom HLMS tutorial is of more important prior( showStopper feature )

Personally I prefer doing one thing right rather than doing many things half baked. Without the tex. refactor Android apps can run out of memory quickly unless they're small games.
But regardless of what I think, there is commercial interest in this feature, hence the priority boost. Also this problem has been bothering me for a time now, and is now getting on my nerve.

I understand some people will prefer focusing on tex. refactor features, other people in Android support. Can't satisfy everyone at the same time unfortunately.

so 1.x "upgraders" can have easier time using 2.1 main branch...as not much of 1.x api would be left after this...also, not everybody is in dire need for this..
i think people forgot a bit about what is the purpose of versioning...isn't part of it is to preserve API state between big changes?

I feel the same. It seems the general consensus is we should bump to 2.2; at least the branch name.

Congratulations for the iniciative Matías, this is great news, the community will benefit greatly from this.

your delecation to ogre is inspiring...

Thanks!
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 3175
Kudos: 484
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby SamiTheGreat » Fri Sep 09, 2016 5:34 am

This sounds great!

dark_sylinc wrote:[*]Loading mipmaps: I forgot to mention that in order to start by loading from the 64x64 mipmaps and below, then load the rest; we need the DDS texture to have the mipmaps already computated (otherwise we would have to load the full res to compute the mips... which beats the point). I also plan on doing a JSON file to specify some texture data (i.e. if you want a specific file to be loaded in a specific format, to be aliased to a different name, etc)
[*]Loading mipmaps: You made me realize I should definitely watch out more carefully about selecting up to which mip you want to load (i.e. quality settings). Thank you.


I've also planned to create a better workflow for us to manage different sized textures (small, medium, large). Loading smaller mips should solve all this stuff to prevent having 3 different files for each setting.

dark_sylinc wrote:I understand some people will prefer focusing on tex. refactor features, other people in Android support. Can't satisfy everyone at the same time unfortunately.


I personally prefer to focus on desktop platform first since there are multiple open source frameworks for mobile already (eg. Cocos2D-x, libGdx etc.) but Ogre3D is the only really good open source solution for desktop.
User avatar
SamiTheGreat
Bronze Sponsor
Bronze Sponsor
 
Posts: 102
Kudos: 8
Joined: 30 Aug 2008
Location: Finland

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby frostbyte » Fri Sep 09, 2016 6:17 am

dark_sylinc:
thought about it a bit... this refactoring can go deep...ogre is turning a bit into a little OS, i think i'm starting to like this lean&mean approach (-:
i can only suggest that you keep the heuristics plugable/programmable so developers will have more control/flex in case of non-conventional use

samiTheGreat:
was actually thinking on use case of gles+lightPBS for old or weak laptop/desktop hardware and OSX...never mind...will come in time...its all GOOD (-: ...

glowingPotato:
one cheap fast dirty "not really a solution" hack i'm aware of for loading stuff fast is using a RamDisk, might shave a few secs...
For this message the author frostbyte has received 64K kudos
frostbyte
Gnoll
 
Posts: 687
Kudos: 42
Joined: 31 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby GlowingPotato » Fri Sep 09, 2016 1:35 pm

dark_sylinc wrote:Things like what you mention about converting TGA to DXT1/BC5 etc fall out of the scope of this refactor. And often need to be customized. However a lot of people will probably have the same needs, so after the refactor we could chat and see if you could contribute your scripts and conversion tools and we facilitate integration with them in Ogre. Since I'm guessing you're using some propietary tools (i.e. not all DDS converters are open source) we may have to provide a binary download option instead. Tools are definitely something we're looking forward for the future of Ogre. At least everyone should be hinted to use the same conventions. i.e. Targetting multiple platforms means we need to convert to DDS, ETC, PVRTC, ASTC and keep things consistent and for quick iteration. Basically, what Unity does.


Absolutely! I will be glad to share those scripts.
to write DDS files, we use a .exe (texconv.exe) found in here -> https://github.com/Microsoft/DirectXTex more info here -> https://blogs.msdn.microsoft.com/chuckw/2011/10/27/directxtex/
User avatar
GlowingPotato
Goblin
 
Posts: 211
Kudos: 10
Joined: 08 May 2013

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby hyyou » Fri Sep 09, 2016 1:44 pm

I call this at 0th frame.
Code: Select all
ogreTexturePtr->getBuffer()->lock() , then get RGB, then unlock(); 

It is v1 function, so I hope there will be a substitute.

I propose that, while Ogre is gradually loading textures, it would return/receive parameter "%progress".
Code: Select all
float progress = Ogre::tryOgresBestToLoadTextureForThisTimeStep(); //or...
Ogre::forceLoadAllTexture(float progressWant);
hyyou
Halfling
 
Posts: 95
Kudos: 4
Joined: 03 Feb 2016

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby SolarPortal » Sat Sep 10, 2016 3:00 pm

wow, exciting times! finally a complete texture system rewrite.
I am certainly interested in the 3 different modes for holding textures and loading in smaller images first to speed up loading time has been something we have wanted in our engine for some time now.
Also, i agree on increasing the ogre version to 2.2.
Thanks again :D
Lead developer of the Skyline Game Engine: http://www.aurasoft-skyline.co.uk
User avatar
SolarPortal
Greenskin
 
Posts: 100
Kudos: 12
Joined: 16 Jul 2011
Location: UK

Re: Texture Streaming Refactor proposal (w/ SLIDES)

Postby GlowingPotato » Mon Sep 12, 2016 1:45 pm

i'am so pumped. :mrgreen: :mrgreen: :mrgreen:

Image

For this message the author GlowingPotato has received 2 kudos
User avatar
GlowingPotato
Goblin
 
Posts: 211
Kudos: 10
Joined: 08 May 2013

Next

Return to Ogre 2.0+

Who is online

Users browsing this forum: No registered users and 3 guests