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 » Tue Oct 05, 2004 8:41 pm

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.
0 x

hatch22
Gnoblar
Posts: 1
Joined: Thu Oct 07, 2004 5:04 pm

Efficient Re-use of Geometry

Post by hatch22 » Thu Oct 14, 2004 9:30 pm

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?
0 x

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

Post by kabutor » Mon Nov 08, 2004 1:35 am

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
0 x

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

Post by Robomaniac » Mon Nov 08, 2004 1:56 am

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

My Webpage

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

Post by kabutor » Thu Nov 11, 2004 12:43 am

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.
0 x

User avatar
IoN_PuLse
Goblin
Posts: 220
Joined: Mon May 31, 2004 5:54 am
Location: Canada
Contact:

Post by IoN_PuLse » Thu Nov 11, 2004 1:16 am

goto???? I'd recommend not using that.
0 x

Crashy
Google Summer of Code Student
Google Summer of Code Student
Posts: 996
Joined: Wed Jan 08, 2003 9:15 pm
Location: Lyon, France
x 20
Contact:

Post by Crashy » Thu Nov 11, 2004 10:36 am

yes, Goto is prohibited in C++. If you want to do such a thing, create a procedure.
0 x
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
Contact:

Post by Falagard » Thu Nov 11, 2004 1:26 pm

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!
0 x

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

Post by kabutor » Sat Nov 27, 2004 1:09 am

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
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sat Nov 27, 2004 1:15 pm

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();
         }
0 x

PJB
Gnoblar
Posts: 19
Joined: Mon Aug 16, 2004 1:48 am
Location: East Sussex, England
Contact:

Post by PJB » Sat Nov 27, 2004 3:37 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sat Nov 27, 2004 4:52 pm

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.
0 x

PJB
Gnoblar
Posts: 19
Joined: Mon Aug 16, 2004 1:48 am
Location: East Sussex, England
Contact:

Post by PJB » Sun Nov 28, 2004 3:01 am

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:
0 x

User avatar
neocryptek
Gnome
Posts: 335
Joined: Sat Mar 01, 2003 11:21 pm
Location: Idaho, USA
Contact:

Post by neocryptek » Sun Nov 28, 2004 5:41 am

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
0 x

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

Post by kabutor » Sun Nov 28, 2004 1:15 pm

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
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sun Nov 28, 2004 5:08 pm

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.
0 x

robin_3d
Kobold
Posts: 27
Joined: Thu Oct 21, 2004 12:32 pm

Post by robin_3d » Tue Nov 30, 2004 9:05 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Tue Nov 30, 2004 11:15 pm

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.
0 x

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

Post by kabutor » Wed Dec 01, 2004 12:36 am

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.
0 x

UrOni
Gnoblar
Posts: 1
Joined: Mon Sep 20, 2004 5:23 pm

Post by UrOni » Sun Dec 05, 2004 4:01 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sun Dec 05, 2004 4:41 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Wed Dec 08, 2004 2:28 pm

Here's my proposal for 'son of GroundCover':
http://www.ogre3d.org/phpBB2/viewtopic.php?p=49131
0 x

tonyhnz
Greenskin
Posts: 101
Joined: Fri Feb 25, 2005 3:54 am
Location: Florida

Post by tonyhnz » Fri Mar 11, 2005 8:11 pm

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.
0 x

User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
Contact:

Post by haffax » Fri Mar 11, 2005 8:50 pm

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

Post Reply