Ogre Forums

Posted: **Fri Mar 21, 2014 5:30 am**

dark_sylinc wrote:
Klaim wrote:I'm re-iterating my question in case nobody noticed it: is the new resource management system planned to be merged for the CTP or later?
It's not going to be in the CTP.
Now as for the final version, we'll see.
I'd like to wait and release final without the resource changes, but at the same time I don't want to introduce another ground-breaking change after saying "this is the final version".
We have yet to analyze the state of the new resource system and evaluate how easy it is to port.

Cheers
Matias

For what it's worth, I understand not including it in the CTP. People are getting restless to see the changes that have been talked about for over a year now. But I feel the resource system changes really should be in the final version for both the reason you mentioned (correcting API breaks in multiple sessions suck), but also the resource system changes is another thing that people have been waiting on for while now. For me personally, it's the last piece of Ogre 2.0 before I will take the plunge.

Posted: **Fri Mar 21, 2014 9:11 am**

I have to agree missing the resource system redesign out would be a bad thing as it's a major change (more changing from sync to async though as I recollect). But I don't think it is required in the first CTP there is usually multiple CTP untill final API is decided.

Of course we do need to know the state of play with the changes maybe owen will give some info

Posted: **Fri Mar 21, 2014 9:25 am**

The thing is that the new ResourceSystem is still not completed nor tested on all platforms we support. From my point of view its unrealistic to talk about integration instead we should talk about completion. (Just my 2 cents)

Posted: **Fri Mar 21, 2014 1:02 pm**

I guess it depends on the release timing for 2.0 then. If 2.0 comes fast after the CTP (and there is not several CTP), then I guess the new resource system will have to wait a future 2.x version (when it's actually finished and tested).

Anyway, ok, not in CTP.

Posted: **Fri Mar 21, 2014 1:58 pm**

Yeah I have to agree I checked through the thread a bit and it's in a unknown state he hasn't come back with a concrete list of work remaining either. (sorry if I missed it)

Posted: **Tue Mar 25, 2014 11:45 am**

dark_sylinc wrote:Mobile devs will love it. Advanced features (like TagPoints) aren't usually required, and Ogre's 2.0 huge performance benefits will be welcomed in these platforms.

I'm not a mobile dev, I'm a simulator dev but I love it, too.

I'm not sure about a CTP. On the one hand it is a good idea to give a preview for everybody who like to change to 2.0 about the necessary changes. On the other hand this could be done with 2.0 and the next steps (new resource system, etc.) are upwards to 2.1. Also it's possible to insert one or more small steps like 2.0.1 between 2.0.0 and 2.1.0 for bug fixing etc.

Posted: **Wed Apr 30, 2014 8:52 am**

Hi, I've just made a pull of Ogre 2.0 and I've some compiling errors in OgreCompositorShadowNode:

error C2065: 'ssize_t' : undeclared identifier

I'm using Visual 2008 Express, seems this type is not defined.

I replaced it with size_t and it's ok as the parameters of the std::max function are size_t.
Is there another way to solve this compile error?
Thanks.

Posted: **Wed Apr 30, 2014 12:42 pm**

I'm pretty sure it's supposed to be a size_t.

Posted: **Wed Apr 30, 2014 3:03 pm**

Oops, sorry. I thought I fixed the bug but turns out I pushed it to the wrong repo. I'll be pushing the fix in a few mins.

The correct is std::max<signed>; as the operation has to be made using signed numbers, otherwise std::max<size_t>( startLight - mCurrentLightList.size(), 0 ) makes no sense (the result is always >= 0)
ssize_t stands for signed size_t; but then I discovered VS 2008 didn't have it.

Posted: **Wed Apr 30, 2014 4:07 pm**

I just saw the whole log; there's some other WIP stuff mixed with it, so the fix is going to have to wait for a little.

Posted: **Wed Apr 30, 2014 5:09 pm**

No problem, I've made the change on my side. Thanks.

Posted: **Mon Jun 23, 2014 8:34 pm**

What status 2.0?Is ready for porting from 1.9 or wait?
what i problems i can get?

My components:
1)Octree Scene Manager
2)Terrain
3)CgProgramManager
4)ParticleFX

Posted: **Tue Jun 24, 2014 12:52 am**

nickG wrote:1)Octree Scene Manager

Doesn't exist anymore. Was too slow and poorly written.

nickG wrote:2)Terrain

Overall works. Not sure that the shadows work properly though. David (masterfalcon) has been doing the porting.

nickG wrote:3)CgProgramManager

Works.

nickG wrote:4)ParticleFX

Works. Minor bugs might appear here and there, report them and we'll try to get them fix.

Posted: **Tue Jun 24, 2014 8:32 am**

I tried to compile the current 2.0 branch with mingw32 and ran into two problems.
The first one is that the linker crashes with an out of memory error when compiling the debug version of OgreMain. I fixed it by modifying ld.exe with the "largeaddressaware" flag so that it could allocate more than 2Gb of memory and it ran fine.
Then everything compiles and links fine, but I can't run anything. The sample browser, mesh upgrader and xml converter, debug and release versions, all crash with the same error code (0xc0000142) which according to google indicates a fail while attempting to load the dll.
I tried afterwards to pull the 1.9 branch and I had no problem compiling, linking and running the sample browser.
What am I doing wrong? This kind of problem is really out of my league. The windows application log doesn't help a lot either, except to say that the dll generating the error is Ogremain.

Thanks for you ideas!

Posted: **Tue Jun 24, 2014 8:50 am**

dark_sylinc wrote:
nickG wrote:1)Octree Scene Manager
Doesn't exist anymore. Was too slow and poorly written.

Is it replaced by an alternative or not yet?

Posted: **Tue Jun 24, 2014 8:59 am**

Posted: **Tue Jun 24, 2014 9:22 am**

Is there plans for to rewrite it? If yes, do you need help on this?

I plan to switch to something like the portal scene manager (but maybe a custom one...not sure yet) but I think it might get the same treatment for 2.0, right?

Posted: **Tue Jun 24, 2014 3:46 pm**

Klaim wrote:Is there plans for to rewrite it? If yes, do you need help on this?

On the very long term, yes. On the short term, no.
Basically I'm just focusing on the elephant on the room (before we write a SceneManager that allows vast/huge landscapes on scene, we need to have many objects on the same area with decent performance -> API overhead)

Help is accepted if you wish. The idea hasn't changed since my 2.0 proposal slides: The base SceneManager class has the following pointers:

Code: Select all

NodeMemoryManager       mNodeMemoryManager[NUM_SCENE_MEMORY_MANAGER_TYPES];
ObjectMemoryManager     mEntityMemoryManager[NUM_SCENE_MEMORY_MANAGER_TYPES];
ObjectMemoryManager     mLightMemoryManager;
SkeletonAnimManager     mSkeletonAnimationManager;

We use them to iterate through objects (and keep it's memory). The scene manager would have one of these per region.
For example if you're in a 32x32km island; divide the island in 16 regions (i.e. a 4x4 2D grid; or 32 regions in a 4x4x2 grid).
Overload virtual void highLevelCull which gets called every frame, and add the mem. managers of the regions that are visible by all cameras to these lists:

Code: Select all

NodeMemoryManagerVec    mNodeMemoryManagerUpdateList;
ObjectMemoryManagerVec  mEntitiesMemoryManagerCulledList;
ObjectMemoryManagerVec  mEntitiesMemoryManagerUpdateList;
ObjectMemoryManagerVec  mLightsMemoryManagerCulledList;
SkeletonAnimManagerVec  mSkeletonAnimManagerCulledList;

Of course, book-keeping when an object migrates from one region to another is your job (the memory managers provide facilities for this, see NodeMemoryManager::migrateTo). The hint SCENE_STATIC means you don't have to check these objects very often, because they're not supposed to move (they can, but you get notified explicitly)

The idea is to skip very big group of objects from culling (and for skeletons, from updating), not trying to micro-manage culling (i.e. like a BSP) because we're really good at micro-culling (i.e. frustum culling) big groups of objects.
This way you could render huge, I mean huuuuuuuuuuuuuuge cities or wilderness (think big like Assassin's Creed III or GTA 5) at high frame rates

Posted: **Tue Jun 24, 2014 5:49 pm**

Ok noted, I'll see what I can do then, I should be able to at least start an implementation tomorrow.
I've done quadtree culling before so I see what to do aproximatively but it was a long time ago. I guess it will also help me later to make a custom portal-connected-scenes manager later for my specific case (if it's not already pre-allowed by the Ogre 2.0 design, like if scene managers were nodes in a tree of scene managers but I'm going crazy I guess).

I suspect the current Ogre 2.0 repository to be stable enough to allow me to test that scene manager implementation, right? I "just" have to rewire the current samples using the previous scene manager once I have the new manager? Or do you recommend I start with a specific more stable change-set?

Posted: **Tue Jun 24, 2014 6:32 pm**

Klaim wrote:Ok noted, I'll see what I can do then, I should be able to at least start an implementation tomorrow.
I've done quadtree culling before so I see what to do aproximatively but it was a long time ago. I guess it will also help me later to make a custom portal-connected-scenes manager later for my specific case (if it's not already pre-allowed by the Ogre 2.0 design, like if scene managers were nodes in a tree of scene managers but I'm going crazy I guess).

Yes.
Though there might be a few "quircks", most notably SceneManager::_getEntityMemoryManager; which retrieves directly a memory manager without being aware that there could be multiple mgrs.

This is used in the DefaultSceneQueries although that one shouldn't be aproblem because you would overload those.
It is also used by the InstanceManager to temporarily create dummy batches (shoudln't be a problem then).
StaticGeometry is used. I'm going to rewrite StaticGeometry at some point because everything I do ends up breaking it, so I wouldn't worry about it.
It is being used by the Terrain component. This could be a problem (though you could treat the terrain as a special case and use the pointer returned by _getEntityMemoryManager as a global list outside your tree...)
It is being used by two samples (Deferred Shading & VolumeTex). VolumeTex shows that we clearly need a specific interface (i.e. tell where the renderable will be placed when retrieving the ptr) when using SimpleRenderables

Klaim wrote: I suspect the current Ogre 2.0 repository to be stable enough to allow me to test that scene manager implementation, right? I "just" have to rewire the current samples using the previous scene manager once I have the new manager?

Yep.

Posted: **Fri Jun 27, 2014 10:16 am**

Questions:
1)Is possible create sample of Tiled DS?
2)is possible use C++11threads instead boost and etc?

Posted: **Fri Jun 27, 2014 11:52 pm**

nickG wrote: 2)is possible use C++11threads instead boost and etc?

Not possible, see http://www.ogre3d.org/forums/viewtopic. ... 34#p503034

Posted: **Fri Jul 04, 2014 7:40 am**

I'm realy fond of the ctp idea...this wil help devs adjust and maybe some tutorials/wiki/plugins will be converted just in time for for stable release...
feels like u can leave the resource system out for now... as it is just ctp...better to bring the changes drop by drop, let people adjust...
Q?: will the eagrly awaited, shiny, magnificent- PBS make it to the ctp?... if not- when is it planned for? will it be the default or just another option?
Q?: regarding the removal of octreeSceneMgr :
i'm realy ignorant about the scene manager...but u've managed to trigger my curiousity so here are a few q?/ideas( careful... stupid ideas ahead...

)
Q:?-will it realy hurt performance for large scenes( 1000 elephents in 1000 rooms )?
-if yes how much?( alot/little...) , will new ogre sceneMgr design make up to it somehow( yes/no/maybe...)?

Ideas:....( no need to comment...)
-does it make sense to move the whole sceneMgr...culling/transforms etc to the gpu somehow( i know its already simd...) with somthing like opencl/shaders/whatever...
-i had the idea of nonliniar adjustable grid for the octreeSceneMgr.... does this make sense?

My deep thanks in advance - makes me happy to hear of the massive progress....

Posted: **Wed Sep 03, 2014 1:27 am**

what is it "CTP"?

2.0 is ready for using?

Posted: **Wed Sep 03, 2014 4:14 am**

nickG wrote:what is it "CTP"?

2.0 is ready for using?

Community Technology Preview.

CTPs implement a set of features of a project so the public can test and evaluate them. There may be multiple CTPs, each implementing new features.

Current 2.0 runs pretty well. I haven't done much with it yet, but I've started using it instead of 1.9 now. But there's still many things on the way for it, it's not ready for an official release yet.

Ogre Forums

Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion

Re: Ogre 2.0 release discussion