Ogre doesn't know what you want static.asdfghu wrote:So why ogre doesnt automatically glue everything static like this class do?tuan kuranes wrote:The idea is to reduce state change in the 3d card. (...)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
Rendering A LOT of things
-
- Gnoblar
- Posts: 4
- Joined: Sat Dec 06, 2003 2:58 am
-
- Gnoblar
- Posts: 1
- Joined: Thu Oct 07, 2004 5:04 pm
Efficient Re-use of Geometry
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?
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?
-
- Gnoblar
- Posts: 18
- Joined: Thu Mar 18, 2004 1:50 am
- Location: Spain and Olé
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)?

-
- Gnoblar
- Posts: 18
- Joined: Thu Mar 18, 2004 1:50 am
- Location: Spain and Olé
Just tried, added .cpp and .h and :
So i just try to compile it :
That means :
(1) - Jump to label jump_hide
(2) - From here
And here is
No idea so far.
Code: Select all
GroundCover* _ground_cover = new GroundCover(mSceneMgr,Vector3(2052,100,2052),32,32);
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 ***
(1) - Jump to label jump_hide
(2) - From here
And here is
Code: Select all
if(sqrlen > (max_dist * max_dist)) goto jump_hide;
-
- Goblin
- Posts: 220
- Joined: Mon May 31, 2004 5:54 am
- Location: Canada
-
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
-
- Gnoblar
- Posts: 18
- Joined: Thu Mar 18, 2004 1:50 am
- Location: Spain and Olé
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:
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
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
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
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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:
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();
}
-
- Gnoblar
- Posts: 19
- Joined: Mon Aug 16, 2004 1:48 am
- Location: East Sussex, England
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.
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.
Pete Baron
antispam_sibaroni@hotmail.com (remove 'antispam_' to mail me)
http://home.btconnect.com/pete/homepage.html
antispam_sibaroni@hotmail.com (remove 'antispam_' to mail me)
http://home.btconnect.com/pete/homepage.html
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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.
Personally I use the command-line 'patch' tool from cygwin ("patch -p0 < thepatch.diff"), but this should do the same thing.
-
- Gnoblar
- Posts: 19
- Joined: Mon Aug 16, 2004 1:48 am
- Location: East Sussex, England
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
edit: I had another query here, but I solved it already lol

Pete Baron
antispam_sibaroni@hotmail.com (remove 'antispam_' to mail me)
http://home.btconnect.com/pete/homepage.html
antispam_sibaroni@hotmail.com (remove 'antispam_' to mail me)
http://home.btconnect.com/pete/homepage.html
-
- Gnome
- Posts: 335
- Joined: Sat Mar 01, 2003 11:21 pm
- Location: Idaho, USA
I noticed this as well, there is a 'Make Patch' option, but no apply patch. Very odd.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
-N30
-
- Gnoblar
- Posts: 18
- Joined: Thu Mar 18, 2004 1:50 am
- Location: Spain and Olé
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:
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
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
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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.
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.
-
- Kobold
- Posts: 27
- Joined: Thu Oct 21, 2004 12:32 pm
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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.
-
- Gnoblar
- Posts: 18
- Joined: Thu Mar 18, 2004 1:50 am
- Location: Spain and Olé
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.
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

-
- Gnoblar
- Posts: 1
- Joined: Mon Sep 20, 2004 5:23 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:
My Parameters:
And how I add the mesh:
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.
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());
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);
Code: Select all
nsGroundCover::InstanceData* ID;
ID=groundcover->add(file,file);
ID->vScale=string2vertex(scale);
ID->qOrient=qu;
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
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.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.
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.
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
Here's my proposal for 'son of GroundCover':
http://www.ogre3d.org/phpBB2/viewtopic.php?p=49131
http://www.ogre3d.org/phpBB2/viewtopic.php?p=49131
-
- Greenskin
- Posts: 101
- Joined: Fri Feb 25, 2005 3:54 am
- Location: Florida