Rendering A LOT of things

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
HeLiuM
Gnoblar
Posts: 4
Joined: Sat Dec 06, 2003 2:58 am

Post by HeLiuM »

asdfghu wrote:
tuan kuranes wrote:
I still can't figure out why 10 different meshes of 50000 polygons each render faster than 500 instances of the same 100 polygon mesh
The idea is to reduce state change in the 3d card. (...)
So why ogre doesnt automatically glue everything static like this class do?
Ogre doesn't know what you want static.
hatch22
Gnoblar
Posts: 1
Joined: Thu Oct 07, 2004 5:04 pm

Efficient Re-use of Geometry

Post by hatch22 »

I don't know if this will help, but I ran accross an article on MSDN that might be of use.

Efficiently Drawing Multiple Instances of Geometry
http://msdn.microsoft.com/library/defau ... tances.asp.

It uses indexed buffers with vertex shaders to reuse geometry in a flexible way. Even though the article says that vertex shader 3.0 support is required, I haven't figured out why 2.0 wouldn't do the job. Any ideas?
kabutor
Gnoblar
Posts: 18
Joined: Thu Mar 18, 2004 1:50 am
Location: Spain and Olé

Post by kabutor »

HeLiuM wrote: Ogre doesn't know what you want static.

Are there any way to tell ogre to make some meshes static ones? Or just use monsters implementation?

I have one hexagon mesh (about 10 faces) and load it 58 x 34 times and well, just get 10 fps, could be better if I did the hexagon manually (by declaring vertex position and so)?

Image
User avatar
Robomaniac
Hobgoblin
Posts: 508
Joined: Tue Feb 03, 2004 6:39 am

Post by Robomaniac »

If you follow monster's code examples and make it a single static mesh, you'll get much better rates
phear hingo

My Webpage
kabutor
Gnoblar
Posts: 18
Joined: Thu Mar 18, 2004 1:50 am
Location: Spain and Olé

Post by kabutor »

Just tried, added .cpp and .h and :

Code: Select all

GroundCover* _ground_cover = new GroundCover(mSceneMgr,Vector3(2052,100,2052),32,32); 
So i just try to compile it :

Code: Select all

compiling GroundCover.cpp (g++)
/home/dday/kdevelop/conquer/src/GroundCover.cpp:239: error: salto a la etiqueta `jump_hide' (1)
/home/dday/kdevelop/conquer/src/GroundCover.cpp:212: error: desde aquí (2)
/home/dday/kdevelop/conquer/src/GroundCover.cpp:215: error: crosses initialization of `Real sqrmin'
*** Exited with status: 2 ***
That means :
(1) - Jump to label jump_hide
(2) - From here

And here is

Code: Select all

if(sqrlen > (max_dist * max_dist)) goto jump_hide;
No idea so far.
User avatar
IoN_PuLse
Goblin
Posts: 220
Joined: Mon May 31, 2004 5:54 am
Location: Canada

Post by IoN_PuLse »

goto???? I'd recommend not using that.
Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 1005
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 49

Post by Crashy »

yes, Goto is prohibited in C++. If you want to do such a thing, create a procedure.
Follow la Moustache on Twitter or on Facebook
Image
User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3

Post by Falagard »

Ya, the groundCover code had a goto. Should be easy to modify it so that it works the same way without the goto.

So... go to it!
kabutor
Gnoblar
Posts: 18
Joined: Thu Mar 18, 2004 1:50 am
Location: Spain and Olé

Post by kabutor »

ok, i figured out how to make Groundcover class go without the goto, but now Im having another problem.

Basically it works fine when I use some meshes but with lots of others it crashs always with the same error:

Code: Select all

Mesh: Loading hexa.mesh.
conquer: OgreMesh.cpp:731: void Ogre::Mesh::createManualLodLevel(float, const Ogre::String&): Assertion `!mEdgeListsBuilt && "Can't modify LOD after edge lists builded"' failed.
Abortado
I made several tests, and even with the same .blend file exporter some time ago it works fine (loads LOTs of palm trees) but if the same model I reexport, without making any change it crashes...

Even crash with simple meshes, like a cube or an Uvsphere.. any hint?

Thanks


EDIT: Im doing some more testing and maybe is related to Atatoth CVS version .. sorry
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

There was a new assert from a mesh patch we received, stopping you from modifying LODs after the edge lists have been built - however since meshes in 0.15 now have edge lists prebuilt by default, it essentially means you can't modify LODs after loading one.

I've reviewed the code and I don't think this restriction is necessary. If you add a new LOD, or modify a LOD, the edge data gets reset, and the getLodLevel() method will rebuild the edge data if it does not exist. Try this patch:

Code: Select all

Index: OgreMain/src/OgreMesh.cpp
===================================================================
RCS file: /cvsroot/ogre/ogrenew/OgreMain/src/OgreMesh.cpp,v
retrieving revision 1.79
diff -u -r1.79 OgreMesh.cpp
--- OgreMain/src/OgreMesh.cpp	23 Oct 2004 15:39:36 -0000	1.79
+++ OgreMain/src/OgreMesh.cpp	27 Nov 2004 12:13:55 -0000
@@ -701,13 +701,16 @@
     const Mesh::MeshLodUsage& Mesh::getLodLevel(ushort index) const
     {
         assert(index < mMeshLodUsageList.size());
-        if (mIsLodManual && index > 0 && mMeshLodUsageList[index].manualMesh == NULL)
+        if (mIsLodManual && index > 0)
         {
-            // Load the mesh now
-            mMeshLodUsageList[index].manualMesh = 
-                MeshManager::getSingleton().load(mMeshLodUsageList[index].manualName);
+			if (!mMeshLodUsageList[index].manualMesh)
+			{
+				// Load the mesh now
+				mMeshLodUsageList[index].manualMesh = 
+					MeshManager::getSingleton().load(mMeshLodUsageList[index].manualName);
+			}
             // get the edge data, if required
-            if (!mAutoBuildEdgeLists)
+            if (!mMeshLodUsageList[index].edgeData)
             {
                 mMeshLodUsageList[index].edgeData = 
                     mMeshLodUsageList[index].manualMesh->getEdgeList(0);
@@ -728,7 +731,6 @@
 	};
 	void Mesh::createManualLodLevel(Real fromDepth, const String& meshName)
 	{
-        assert(!mEdgeListsBuilt && "Can't modify LOD after edge lists builded");
 
 		// Basic prerequisites
         assert(fromDepth > 0 && "The LOD depth must be greater than zero");
@@ -748,7 +750,6 @@
     //---------------------------------------------------------------------
 	void Mesh::updateManualLodLevel(ushort index, const String& meshName)
 	{
-        assert(!mEdgeListsBuilt && "Can't modify LOD after edge lists built");
 
 		// Basic prerequisites
 		assert(mIsLodManual && "Not using manual LODs!");
@@ -1385,7 +1386,7 @@
     EdgeData* Mesh::getEdgeList(unsigned int lodIndex)
     {
         // Build edge list on demand
-        if (!mEdgeListsBuilt)
+        if (!mEdgeListsBuilt && mAutoBuildEdgeLists)
         {
             buildEdgeList();
         }
PJB
Gnoblar
Posts: 19
Joined: Mon Aug 16, 2004 1:48 am
Location: East Sussex, England

Post by PJB »

A little off-topic here, but is it possible to apply the 'patch' changes as listed above to my local copy of the file automatically, or must I type them all in by hand?
It seems like that patch file should be applicable completely automatically (with obvious failsafes in case the '-' lines don't match what's found in the code) but I can't see any indication that tortoise CVS will support this.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

I don't use Tortoise CVS, but I have Tortoise SVN for another project and I assume the approach is the same. Save that text above as a file, the right-click on the ogrenew folder, and select TortoiseCVS > Apply Patch, then pick the patch file.

Personally I use the command-line 'patch' tool from cygwin ("patch -p0 < thepatch.diff"), but this should do the same thing.
PJB
Gnoblar
Posts: 19
Joined: Mon Aug 16, 2004 1:48 am
Location: East Sussex, England

Post by PJB »

Thanks for the reply Sinbad, I've looked into that but Tortoise CVS doesn't seem to have that option available - I checked the online documentation for it too and didn't find any mention of this feature, perhaps it's limited to the SVN version or maybe I'm just missing something entirely!

edit: I had another query here, but I solved it already lol :oops:
User avatar
neocryptek
Gnome
Posts: 335
Joined: Sat Mar 01, 2003 11:21 pm
Location: Idaho, USA

Post by neocryptek »

PJB wrote:Thanks for the reply Sinbad, I've looked into that but Tortoise CVS doesn't seem to have that option available - I checked the online documentation for it too and didn't find any mention of this feature, perhaps it's limited to the SVN version or maybe I'm just missing something entirely!

edit: I had another query here, but I solved it already lol :oops:
I noticed this as well, there is a 'Make Patch' option, but no apply patch. Very odd.

-N30
kabutor
Gnoblar
Posts: 18
Joined: Thu Mar 18, 2004 1:50 am
Location: Spain and Olé

Post by kabutor »

For what I see, correct me If Im wrong is that the patch is already commited in hastur CVS right? I changed to that to avoid the unestable bracnch.

So Im trying again and now it Segfaults, Im trying to debug it with gdb and the output:

Code: Select all

Mesh: Loading hexa.mesh.
Items to compile = 500
Total blocks = 405

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 1289)]
0x08054a76 in Ogre::VertexElement::getSource() const ()
(gdb) bt
#0  0x08054a76 in Ogre::VertexElement::getSource() const ()
#1  0x08052181 in GroundCover::Block::copyVertexData(Ogre::Vector3 const&, Ogre::VertexData*, Ogre::VertexData*, unsigned char*, unsigned*) ()
#2  0x08051bed in GroundCover::Block::build(Ogre::Mesh*) ()
#3  0x080505aa in GroundCover::compile() ()
#4  0x0804c2ba in principal::createScene() ()
#5  0x0804c7e3 in ExampleApplication::setup() ()
#6  0x0804be5a in ExampleApplication::go() ()
#7  0x0804bcdc in main ()
(gdb) quit
I upload the mesh in case someone wanna try http://www.pccable.es/hexa.mesh its just an hexagon.. I tried also with a cube.mesh same segfault
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

That looks like the GroundCover::copyVertexData method is making assumptions about the vertex buffer structure. Another user had this problem going from 0.14 to 0.15 - basically they had been copying vertex data the 'wrong' way which had worked in 0.14 but wouldn't in the more general sense. In 0.15 we use more options in the .mesh structure which is why it's broken.

Look at the copyVertexData method and modify it so that it doesn't assume a single vertex buffer structure. I suspect it's assuming one element per buffer, which is not the case in the newer .mesh structure. An example of how to parse vertex buffer data generically is contained in VertexData::reorganiseBuffers.
robin_3d
Kobold
Posts: 27
Joined: Thu Oct 21, 2004 12:32 pm

Post by robin_3d »

Hi Sinbad,

Is this code going to become part of the engine?
I reckon a new demo to come with ver 1, showing loads of stuff (like a forest) rendered at the same time would be a huge selling point from a graphics engine point of view.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

It's on my 'maybe if I have time' list. However, I'd have to rewrite it - that's not to say it isn't useful in it's current form, but if it's be part of Ogre it needs to be more generalised to allow it to take advantage of scene manager optimisations. If you want to use it I advise adapting the one monster has posted, it appears it needs some work for 0.15 in any case.
kabutor
Gnoblar
Posts: 18
Joined: Thu Mar 18, 2004 1:50 am
Location: Spain and Olé

Post by kabutor »

What I really liked to hear is more "feedback" from the ppl that are using Monster's GroundCover..

What I mean is that its a real useful piece of code, render statically a lot of meshes is really nice, and the first tests I did show that the fps gain is huge, and that without using the LOD option.

But, after 4 pages of posts only I have problems wth the GOTO in the code (don't know why don't ask me, I only quote what g++ says..) and only I have problems with the new mesh format?

So what I think is that Im doing something really wrong or that is only myself who finds it useful? Someone else have same problems or just me?

And thx for the hint to try to fix it but my knowledge is not enough for that crawling in the Ogre code ;) so Im trying to do things other way.
UrOni
Gnoblar
Posts: 1
Joined: Mon Sep 20, 2004 5:23 pm

Post by UrOni »

I'm also using this realy usefull peace of code...

It'works with OGRE 0.15 with the patch above. But when I go to the center of the built mesh I get an Allocation error in Detail::addMesh(..)
where:

Code: Select all

Entity* ent = _manager->createEntity(_node->getName() + "_" + pInst->pMesh->getName() + "_" + StringConverter::toString((unsigned int)nodes->size()), pInst->pMesh->getName());
My Parameters:

Code: Select all

Ogre::Vector3 v3WS(9999,9999,9999);
int iXblocks=1;
int iYblocks=1;
groundcover=new nsGroundCover::GroundCover(mSceneMgr,v3WS,iXblocks,iYblocks);

groundcover->setCullParameters(999,99999,360);
And how I add the mesh:

Code: Select all

nsGroundCover::InstanceData* ID;
ID=groundcover->add(file,file);
ID->vScale=string2vertex(scale);
ID->qOrient=qu;
With kabutor's mesh my app crashes also in getsource();. My mesh doesn't crash... it was exportet with Milkshape exporter and upgraded with MeshUpgrader.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

UrOni wrote: With kabutor's mesh my app crashes also in getsource();. My mesh doesn't crash... it was exportet with Milkshape exporter and upgraded with MeshUpgrader.
The difference will be that you didn't reorganise the mesh using the 'automatic' mode when you upgraded it, so it still retains it's 0.14 structure. Had you reorganised the mesh (to the more efficient 0.15 format) or exported from the 0.15 export (which defaults to the new optimised format( you would have the same problem.

This piece of code is essentially 'in the community' now - unless Monster feels like supporting it further you should expect to have to resolve any problems with it yourself.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

Here's my proposal for 'son of GroundCover':
http://www.ogre3d.org/phpBB2/viewtopic.php?p=49131
tonyhnz
Greenskin
Posts: 101
Joined: Fri Feb 25, 2005 3:54 am
Location: Florida

Post by tonyhnz »

Does someone have a working link to this code as the links mentioned in the thread do not seem to exist anymore.
Thanks in advance.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 7

Post by haffax »

Since the latest Ogre 1.0 has its StaticGeometry, which is more flexible, this code got obsolete.
team-pantheon programmer
creators of Rastullahs Lockenpracht