How I ported my project to Ogre 2.1

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
Post Reply
Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

How I ported my project to Ogre 2.1

Post by Dugi »

Hello,

After dealing with a lot of issues, I managed to port my project from Ogre 1.9 to Ogre 2.1 with everything working (again). Except a few things that aren't currently doable in Ogre 2.1. I would like to share some information about issues I faced because somebody else might have the same problems and would have to spend a lot of time reinventing the wheel.

1. Getting the stuff to compile
The official porting manual helped me a lot with this, but there were a few cases when I had to look at the documentation or even the source code. Adding the number 2 behind many class names helped a lot. RTSS had to be removed completely, but HLMS did its work pretty well, so all I had to do was to change material codes (accepted arguments are quite hidden, they're in the documentation of the specific HLMS datablock constructors) and initialise HLMS instead of RTSS. SdkTrays no longer compile, it gave me a kick to finally stop using the last bits of it and replace it with CEGUI. Terrain was removed, and there is no replacement (hopefully, there will be one soon, I don't feel like making one myself just to realise that a much better one is being made).

The way the startup is done has also changed quite significantly, but fortunately, the porting manual explains this well enough. The samples' transition to SDL2 motivated me to get rid of the old and obsolete OIS (used because it was in the old samples) and use SDL2 instead. It gave me a much better desktop integration, I can still alt+tab away if I get a freeze and non-english keyboards do not kill input.

This piece of code written by someone I don't know (username jserve on CEGUI forums) helped me a lot, although I mixed it with the v2 samples' code to set up the SDL2 window, get its handle and make ogre render into its window.
I can make some sort of v2 AdvancedOgreFramework if somebody helps me with writing compilation scripts, I am really bad at that.

Replacing Ogre::Entity with Ogre::Item often worked with find 'n' replace, most method names remained identical. The removal of mandatory entity names could cause mess in Ogre::SceneManager::createItem() arguments, so this had to be gone through manually, but entity names were mostly of little use and it was often a nuisance to generate loads of unique names. Skeletal animations changed, but it's mostly about names of objects. Animation weight is now a public member variable, which is a bit counter-intuitive, but definitely not bad.

2. Worsened threading support with SceneNode
With Ogre v1, I could construct the SceneNode tree from other threads without problems, so I could do a lot of scene rebuilding on a background thread. It was possible to prepare all resources for all meshes and then could construct and attach the entities at the end, committing the changes, which could make massive changes to the scene without framerate drops.

With Ogre v2, constructing SceneNodes is no longer thread safe. It's still possible still do all the construction logic (like procedurally generated levels) on background thread, but it seemed necessary to write all the output in a buffer that the rendering thread would read and commit. I have found a partial workaround, to create and fill a storage of nodes on the rendering thread and set all the orientations, positions, scales and other stuff on the background thread, so that there's no need to store and copy these on the rendering thread. I don't know how meaningful it actually is.

3. Lighting issues
There was darkness. The scene appeared to have no lights, light-ignoring particles were the only visible things. I eventually googled that Forward3D has to be enabled in SceneManager (shortly afterwards, it was written in Questions and Answers), but that totally wrecked the performance. I had frame drops to about 1 FPS almost all the time. After a frustrating investigation, I learned that if I use setAttenuationBasedOnRadius() on point lights instead of setAttenuation(), the frame drops vanish. I really liked the old attenuation, because the scene can be well lit without massive radii of the lights' reach.

4. HLMS loads all stuff at startup
Investigation why the game took so long to start up and consumed humongous amounts of memory has led me to a discovery that HLMS constructs all materials while parsing the scripts, loading all necessary textures in the process. This can be practical for games with levels, where everything needed for a level is loaded when entering the level. However, for an open world game with a large exterior area, it is a problem. Even worse if many areas details are procedurally generated, so it's impossible to tell what will be needed.

I have found a trick to deal with it, however. I renamed all files with material scripts to files with a .materials suffix, causing HLMS manager to ignore them. During startup, they are parsed by a function that splits them into strings, one for each material. When a material is needed, its script is looked up and the string is parsed with Ogre::ScriptCompiler (which is capable of parsing strings as well as files). This however needs a special function to create entities (and a special function to destroy entities, because it's necessary to keep track of the materials' usage).

5. No background resource loading (unsolved)
It appears to be impossible to load stuff in the background. This is annoying, if the player walks, let's say, from a forest into a city, the city's resources need to be loaded and when this is done on the rendering thread, the game becomes quite jerky for a while. Doing it by bits on every frame isn't good enough, some textures are large.

The impossibility to compile scripts in the background isn't so bad, no disk reads are necessary and it can be done script by script, one or two per frame, but the textures must be prepared. The above mentioned trick to compile scripts only when needed can be used to read all textures needed by the script and prepare them ahead, but it has a problem. While Ogre::TextureManager does have a method named prepare() that accepts an argument if it should be loaded on the background, it appears to load on the rendering thread anyway.

6. CEGUI
While CEGUI was ported to Ogre 2.1 and its API is the same, the bootstrap has changed a bit to:

Code: Select all

CEGUI::OgreRenderer::bootstrapSystem(*renderWindow_); // returns a reference to CEGUI::OgreRenderer
Also, to make it visible, it is necessary to place this into the frameRenderingQueued of a child of a registered Ogre::FrameListener (this is very unobvious):

Code: Select all

	CEGUI::System::getSingleton().injectTimePulse(evt.timeSinceLastFrame);
	CEGUI::System& guiSystem = CEGUI::System::getSingleton();
	guiSystem.injectTimePulse(evt.timeSinceLastEvent);
	CEGUI::Renderer* guiRenderer(guiSystem.getRenderer());
	guiRenderer->beginRendering();
	guiSystem.getDefaultGUIContext().draw();
	guiRenderer->endRendering();
	CEGUI::WindowManager::getSingleton().cleanDeadPool();
7. HLMS Unlit too limiting (unsolved)
Ogre 2.1 does not support fixed function pipeline anymore, meaning that the classical materials no longer work. While it was poor for PBS and often needed RTSS or custom shaders, the old scripts allowed a lot of cool effects like halo, lightnings, aureola, corona etc. HLMS Unlit seems quite insufficient. While it does support multiple materials and their vivid combinations with operations, it does not seem to support animations.

An item with a skeletal animation will not be animated when its material comes from HLMS Unlit. This is quite a bummer because animated unlit items can do a lot of effects that would be hard to do and consume a lot of CPU time if done with particles. A semi-transparent wispy ghost can't be done at the moment. A tornado-like particle system would require huge amounts of particles and complicated affectors, while a properly textured mesh would only need some writhing and twisting animations. With particles, explosions look mostly like flames erupting from a location, an animated entity can create a very nice blast wave with debris. Creating a force field armour on characters is outright impossible with particles.

I also haven't figured out how to animate the material, like scrolling textures (for tornadoes) or looping between a few textures (for electric discharges). The description says that it can accept an animate argument, it does not explain what do the numbers mean. The source code seem to suggest that they refer to some matrices, but I could not find how to define these matrices. It does not seem to support looping between textures at all. Making a custom HLMS for these few things look like an overkill.

8. Performance
The performance is hard to compare because HLMS materials are different from RTSS materials and AttenuationBasedOnRadius needs massive radii to illuminate the area properly, causing many lights to affect objects faintly (if the radius is high) or create ugly edges where the light is cut off (when the threshold is high). It was probably not intended for illuminating areas, just for making small lights. The usual attenuation could help a lot here, but its implementation with Forward3D has weird performance problems as described above.

A big improvement I have noticed is that the rendering thread takes very little CPU time even if the framerate is not limited (testing it on a poor video card, though). I can't remember seeing a game not consume significant portions of CPU time unless it's something with little demands. In this, Ogre really has Almost Zero Driver Overhead.

9. Conclusion
I hope this report will be useful to somebody. And hopefully some of the unsolved issues will be addressed. Thanks for reading this long post.

Appendix 1. Update to Ogre 2.1 after the merge of the PSO branch

Most changes were trivial and their fixes are intuitive. A namespace change requiring the removal of the ::v1 part, replacing some IdStrings with actual strings. Target swapping is done a bit differently, but the difference can be checked in Ogre's source.

The main unexpected trap I would like to share with others to avoid the issues I had is that it suddenly begun to throw this shortly afters startup:

Code: Select all

An exception has occurred: OGRE EXCEPTION(5:ItemIdentityException): Parameter called f3dGrid does not exist.
The problem was that the hlms templates also had to be updated and new folders had to be added into resources.

CEGUI could be ported to use PSO with the use of the patch on this thread: http://www.ogre3d.org/forums/viewtopic. ... 1&start=25

Compared to 1.9, features that Ogre 2.1 still sickly misses are animations in HlmsUnlit and support for resource loading on background threads.
Last edited by Dugi on Tue Jun 20, 2017 9:34 pm, edited 1 time in total.

xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 166

Re: How I ported my project to Ogre 2.1

Post by xrgo »

Thank you so much, this definitely will be useful for someone.
Dugi wrote:Terrain was removed, and there is no replacement
there is one! see the Terra sample, I think it still have some little bugs though..
Dugi wrote:With Ogre v2, constructing SceneNodes is no longer thread safe
you sure? I was sure it was thread safe... =(

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4549
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 955
Contact:

Re: How I ported my project to Ogre 2.1

Post by dark_sylinc »

Yes!!! This is very useful Feedback!

Thank you!
With Ogre v1, I could construct the SceneNode tree from other threads without problems, so I could do a lot of scene rebuilding on a background thread. It was possible to prepare all resources for all meshes and then could construct and attach the entities at the end, committing the changes, which could make massive changes to the scene without framerate drops.
I'm surprised you were able to construct SceneNodes from other threads back in 1.x. It wasn't thread safe back then either. I guess it was just less apparent.
Anyway, Mike Acton already had pointed out we didn't have a way to prepare SceneNodes ahead of time asynchronously and gave a few hints. Sadly we haven't yet got the time to focus on this.
I'm glad at least you found a workaround.
Terrain was removed, and there is no replacement (hopefully, there will be one soon, I don't feel like making one myself just to realise that a much better one is being made).
The PSO branch has Terra. It has a few rough edges to polish yet, but it will be the replacement. The PSO branch is stable, though you may or not may have a few compiler errors to address when switching (should be nothing major though).
There was darkness. The scene appeared to have no lights, light-ignoring particles were the only visible things. I eventually googled that Forward3D has to be enabled in SceneManager (shortly afterwards, it was written in Questions and Answers), but that totally wrecked the performance. I had frame drops to about 1 FPS almost all the time. After a frustrating investigation, I learned that if I use setAttenuationBasedOnRadius() on point lights instead of setAttenuation(), the frame drops vanish. I really liked the old attenuation, because the scene can be well lit without massive radii of the lights' reach.
A few points:
  • If you're not doing HDR, you probably want to set your light's power to PI. light->setPowerScale( Ogre::Math::PI ); whereas in Ogre 1.x you would like it to be left at 1.
  • setAttenuation still works, but it works differently than setAttenuationBasedOnRadius. The latter calculates attenuation parameters automatically based on a % threshold and a radius for physically based solutions gathered from real data. But the radius is NOT how much to cover but rather how big the light source is. For example a light bulb is typically only a few centimeters, a prison spotlight reflector can be 28cm in radius (according to the website it's 560mm diameter). Logically, smaller radius result in dimmer lights (and thus, smaller range) and a higher % threshold results in a smaller range while still trying to maintain the light brightness.

    setAttenuation gives you full manual control over the attenuation parameters even if the combination isn't physically possible. The most important one for performance is attenuation range. The smaller the range the better it is for performance.
    It's also possible for you to first call setAttenuationBasedOnRadius (to use real world data) and later call setAttenuation:

    Code: Select all

    light->setAttenuationBasedOnRadius( radius, threshold ):
    light->setAttenuation( myCustomRange, light->getAttenuationQuadric(), light->getAttenuationLinear(), light->getAttenuationConstant() );
    so that you we calculate the attenuation parameters for you based on real data, and later you let the artist tweak the range (which is artist intuitive. i.e. it's literally how big the light should cover)
Investigation why the game took so long to start up and consumed humongous amounts of memory has led me to a discovery that HLMS constructs all materials while parsing the scripts, loading all necessary textures in the process.
I'm designing a new system to solve this problem. Effectively the current system has all the pros and cons you mentioned and it has proven to be our weakest point right now.
The goals of the new system is to allow texture streaming, controlling memory residency and get good performance by batching textures into arrays behind the scenes. Can't give an ETA as it is still in the planning phase. But I don't think it will be soon.

Note that, particularly on D3D11 but also affects OpenGL in less extent, shader compilation can also add up significant framerate spikes (which can often correlate with textures popping in). Best way to solve that is using the microcode cache.
An item with a skeletal animation will not be animated when its material comes from HLMS Unlit. This is quite a bummer because animated unlit items can do a lot of effects that would be hard to do and consume a lot of CPU time if done with particles. A semi-transparent wispy ghost can't be done at the moment. A tornado-like particle system would require huge amounts of particles and complicated affectors, while a properly textured mesh would only need some writhing and twisting animations.
Thanks for this feedback! I thought "who the hell would need skeletal animation in Unlit" and now you've given a fair case point. We should be able to add this feature with relatively few pain and work. Added to my TODO list.
I also haven't figured out how to animate the material, like scrolling textures (for tornadoes) or looping between a few textures (for electric discharges). The description says that it can accept an animate argument, it does not explain what do the numbers mean. The source code seem to suggest that they refer to some matrices, but I could not find how to define these matrices.
Don't worry, you're not crazy. That part is WIP. I started writing the animation system to support scrolling/scaling/translating, but never got it finished, then it got lower and lower in priority and there still is... unfinished. Can't give you an ETA yet. But it's certainly in our schedule to tackle it and give proper examples and docs.
or create ugly edges where the light is cut off (when the threshold is high)
You may want to checkout the latest version as we've added a smooth fade so there are no sharp cutoffs :)

Thanks for the feedback!

Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: How I ported my project to Ogre 2.1

Post by Dugi »

dark_sylinc wrote:The PSO branch has Terra. It has a few rough edges to polish yet, but it will be the replacement. The PSO branch is stable, though you may or not may have a few compiler errors to address when switching (should be nothing major though).
I need CEGUI and FAQ tells that it doesn't work with PSO. Limiting myself to caves and dungeons is easier than living without CEGUI, reworking the exterior and creating some alternative to PagedGeometry is not the most important thing at the moment. I don't think that I possess the knowledge necessary to port it. Or am I wrong?
dark_sylinc wrote:
  • If you're not doing HDR, you probably want to set your light's power to PI. light->setPowerScale( Ogre::Math::PI ); whereas in Ogre 1.x you would like it to be left at 1.
I am considering using HDR, but no experiments were done on it. I didn't know that it can help with this issue. I will try to enable it and see the difference.
dark_sylinc wrote:
  1. setAttenuation still works, but it works differently than setAttenuationBasedOnRadius
    ....
    setAttenuation gives you full manual control over the attenuation parameters even if the combination isn't physically possible. The most important one for performance is attenuation range. The smaller the range the better it is for performance.
    It's also possible for you to first call setAttenuationBasedOnRadius (to use real world data) and later call setAttenuation:

    Code: Select all

    light->setAttenuationBasedOnRadius( radius, threshold ):
    light->setAttenuation( myCustomRange, light->getAttenuationQuadric(), light->getAttenuationLinear(), light->getAttenuationConstant() );
    so that you we calculate the attenuation parameters for you based on real data, and later you let the artist tweak the range (which is artist intuitive. i.e. it's literally how big the light should cover)
Strange thing is that I am not able to reproduce those massive FPS drops now, maybe some update fixed it. I can't tell much now. I will try to remember this when the issue reappears. If it reappears.
I don't think that it's necessary to follow physically possible solution. Humans aren't able to tell if the attenuation is physically possible (unless it's blatantly impossible) or not because we see light intensity on a logarithmic scale.

Btw, making the point lights fade into ambient light could help the many-lights-problem, is there some other way to make PBS ambient light besides 3 directional lights now? At least some constant, uniform while colour.
dark_sylinc wrote:I'm designing a new system to solve this problem. Effectively the current system has all the pros and cons you mentioned and it has proven to be our weakest point right now.
The goals of the new system is to allow texture streaming, controlling memory residency and get good performance by batching textures into arrays behind the scenes. Can't give an ETA as it is still in the planning phase. But I don't think it will be soon.
Good to know that this is being a known issue and a solution is going to be. For now, my workaround is does the job to some extent.
dark_sylinc wrote: Note that, particularly on D3D11 but also affects OpenGL in less extent, shader compilation can also add up significant framerate spikes (which can often correlate with textures popping in). Best way to solve that is using the microcode cache.
Wouldn't the saving of microcode take a lot of memory? If I recall correctly, they are saved together with textures and that takes a lot of memory.

Fortunately, there are no issues with shader compilation, if I watch the terminal output with downclocked CPU, it always hangs long time on the calls to start the preparation of textures asynchronously, not on the compilation.
dark_sylinc wrote: Thanks for this feedback! I thought "who the hell would need skeletal animation in Unlit" and now you've given a fair case point. We should be able to add this feature with relatively few pain and work. Added to my TODO list.
Thank you.
dark_sylinc wrote: Don't worry, you're not crazy. That part is WIP. I started writing the animation system to support scrolling/scaling/translating, but never got it finished, then it got lower and lower in priority and there still is... unfinished. Can't give you an ETA yet. But it's certainly in our schedule to tackle it and give proper examples and docs.
Good to know. Thanks.
dark_sylinc wrote: You may want to checkout the latest version as we've added a smooth fade so there are no sharp cutoffs :)
I will give it a try, it should definitely help a lot.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4549
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 955
Contact:

Re: How I ported my project to Ogre 2.1

Post by dark_sylinc »

Dugi wrote:
dark_sylinc wrote:The PSO branch has Terra. It has a few rough edges to polish yet, but it will be the replacement. The PSO branch is stable, though you may or not may have a few compiler errors to address when switching (should be nothing major though).
I need CEGUI and FAQ tells that it doesn't work with PSO. Limiting myself to caves and dungeons is easier than living without CEGUI, reworking the exterior and creating some alternative to PagedGeometry is not the most important thing at the moment. I don't think that I possess the knowledge necessary to port it. Or am I wrong?
You're correct. I want to write a PSO helper that should make porting CEGUI to PSO very easy, but until then... yeah you don't want to mess with that yet (it's just harder because you'll have to cache the PSOs yourself).
Dugi wrote: I don't think that it's necessary to follow physically possible solution. Humans aren't able to tell if the attenuation is physically possible (unless it's blatantly impossible) or not because we see light intensity on a logarithmic scale.
Well, it's not so much about being perfect PBS (for some people is); but rather the main benefit from PBS is that you can look on wikipedia or Amazon and look up the specs, and enter the data; which cuts a lot of time. It won't guarantee it will look perfect (in fact it probably won't because rasterization is approximate and we don't even have real global illumination), but the artist can use those values as a starting point then tweak from there.
Dugi wrote:Wouldn't the saving of microcode take a lot of memory? If I recall correctly, they are saved together with textures and that takes a lot of memory.
Not really. We have a relatively big project and the cache is <10MB IIRC.
It think once it got as big as 30MB when we were tweaking and editing a lot of stuff.

Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: How I ported my project to Ogre 2.1

Post by Dugi »

dark_sylinc wrote: You're correct. I want to write a PSO helper that should make porting CEGUI to PSO very easy, but until then... yeah you don't want to mess with that yet (it's just harder because you'll have to cache the PSOs yourself).
Thanks for the info. I'll better wait then, it's no big deal at the moment.
dark_sylinc wrote: Well, it's not so much about being perfect PBS (for some people is); but rather the main benefit from PBS is that you can look on wikipedia or Amazon and look up the specs, and enter the data; which cuts a lot of time. It won't guarantee it will look perfect (in fact it probably won't because rasterization is approximate and we don't even have real global illumination), but the artist can use those values as a starting point then tweak from there.
Aha, now I understand what is that good for.
dark_sylinc wrote: It think once it got as big as 30MB when we were tweaking and editing a lot of stuff.
I guess that it would not work well with the manual HLMS compilation manager. Waiting for the texture streaming seems like a better option now, since shader compilation isn't causing much slowdowns at the moment (could be because I am working on OpenGL instead of DirectX).

Thanks for the information.

hydexon
Gremlin
Posts: 164
Joined: Sun Apr 14, 2013 8:51 pm
x 10

Re: How I ported my project to Ogre 2.1

Post by hydexon »

Dugi wrote: 5. No background resource loading (unsolved)
It appears to be impossible to load stuff in the background. This is annoying, if the player walks, let's say, from a forest into a city, the city's resources need to be loaded and when this is done on the rendering thread, the game becomes quite jerky for a while. Doing it by bits on every frame isn't good enough, some textures are large.

The impossibility to compile scripts in the background isn't so bad, no disk reads are necessary and it can be done script by script, one or two per frame, but the textures must be prepared. The above mentioned trick to compile scripts only when needed can be used to read all textures needed by the script and prepare them ahead, but it has a problem. While Ogre::TextureManager does have a method named prepare() that accepts an argument if it should be loaded on the background, it appears to load on the rendering thread anyway.
So there's NO WAY to do background loading externally (not using the long-dead BackgroundLoading Queue from Resource Manager) i was starting to planning to write one since the Helium-based Asset loader failed misserably, because background loading is REALLY useful for my ongoing project.

al2950
OGRE Expert User
OGRE Expert User
Posts: 1221
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 155

Re: How I ported my project to Ogre 2.1

Post by al2950 »

Dugi wrote:
Btw, making the point lights fade into ambient light could help the many-lights-problem, is there some other way to make PBS ambient light besides 3 directional lights now? At least some constant, uniform while colour.
I may have mis-understood you but Ogre current has a very cheap and nasty global illumination, aka ambient light. Check out SceneManager::setAmbientLight

Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: How I ported my project to Ogre 2.1

Post by Dugi »

hydexon wrote:So there's NO WAY to do background loading externally (not using the long-dead BackgroundLoading Queue from Resource Manager) i was starting to planning to write one since the Helium-based Asset loader failed misserably, because background loading is REALLY useful for my ongoing project.
I'd try something with loading it on your own bacground thread and feeding its stream to the resource loader. It would avoid having the rendering thread wait for disk reads, but it will still slow it down. No idea how much would that help.
al2950 wrote:I may have mis-understood you but Ogre current has a very cheap and nasty global illumination, aka ambient light. Check out SceneManager::setAmbientLight
:facepalm: I have read that ambient light wasn't working in 2.1. The thread where it was written was very old and I haven't noticed that it's working fine now. Okay, now I have a working ambient light. Thanks for the reminder.

User avatar
TheOnlyJoey
Halfling
Posts: 53
Joined: Sun Apr 10, 2011 12:05 pm
Location: The Netherlands
x 6
Contact:

Re: How I ported my project to Ogre 2.1

Post by TheOnlyJoey »

If you want a slightly less ugly GI technique (ambient is not really GI, just a fullbright) look into implementing SSDO https://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf
Its a extra step based on SSAO which gives you a single light bounce for GI which actually looks pretty good!

Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: How I ported my project to Ogre 2.1

Post by Dugi »

TheOnlyJoey wrote:If you want a slightly less ugly GI technique (ambient is not really GI, just a fullbright) look into implementing SSDO https://people.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf
Its a extra step based on SSAO which gives you a single light bounce for GI which actually looks pretty good!
Wow, that looks cool. Reflections done efficiently. My project has much greater eyesores than ambient light at the moment, though, so I'll just keep that in mind.

User avatar
devxkh
Halfling
Posts: 84
Joined: Tue Aug 02, 2016 6:07 pm
Location: Germany
x 11

Re: How I ported my project to Ogre 2.1

Post by devxkh »

dark_sylinc wrote:
An item with a skeletal animation will not be animated when its material comes from HLMS Unlit. This is quite a bummer because animated unlit items can do a lot of effects that would be hard to do and consume a lot of CPU time if done with particles. A semi-transparent wispy ghost can't be done at the moment. A tornado-like particle system would require huge amounts of particles and complicated affectors, while a properly textured mesh would only need some writhing and twisting animations.
Thanks for this feedback! I thought "who the hell would need skeletal animation in Unlit" and now you've given a fair case point. We should be able to add this feature with relatively few pain and work. Added to my TODO list.
How are the chances, that this is made in the not so far future?
My little OGRE engine -> FrankE WIP

Dugi
Halfling
Posts: 46
Joined: Tue Jul 23, 2013 2:37 pm
x 7

Re: How I ported my project to Ogre 2.1

Post by Dugi »

Porting to 2.1 after PSO.

Most changes were trivial and their fixes are intuitive. A namespace change requiring the removal of the ::v1 part, replacing some IdStrings with actual strings. Target swapping is done a bit differently, but the difference can be checked in Ogre's source.

The main unexpected trap I would like to share with others to avoid the issues I had is that it suddenly begun to throw this shortly afters startup:

Code: Select all

An exception has occurred: OGRE EXCEPTION(5:ItemIdentityException): Parameter called f3dGrid does not exist.
The problem was that the hlms templates also had to be updated and new folders had to be added into resources.

CEGUI could be ported to use PSO with the use of the patch on this thread: http://www.ogre3d.org/forums/viewtopic. ... 1&start=25

Compared to 1.9, features that Ogre 2.1 still sickly misses are animations in HlmsUnlit and support for resource loading on background threads.

Post Reply