
Rendering A LOT of things
-
- OGRE Retired Moderator
- Posts: 4011
- Joined: Fri Sep 19, 2003 6:28 pm
- Location: Burgos, Spain
- x 2
-
- Gnome
- Posts: 327
- Joined: Sat Jul 10, 2004 6:46 pm
- Location: Sweden
- x 4
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- OGRE Retired Moderator
- Posts: 4011
- Joined: Fri Sep 19, 2003 6:28 pm
- Location: Burgos, Spain
- x 2
-
- Platinum Sponsor
- Posts: 243
- Joined: Fri Oct 03, 2003 5:57 am
- Location: Sweden
- x 2
Got some questions about GroundCover class. After some troubles (Had to move Block class etc out of GroundCover class, fixed redefintions and some reserved words in variable names such as "near", "far") I got it almost to compile on VC6 but Im stuck now with 3 errors:
Im using Ogre 14.0. Is SetVisible on SceneNode (or maybe Node) class a new method introduced in 14.1 or CVS branch? Anyway, if I comment out those lines it does compile but I get some strange behaviours which I guess comes from those removals. Just wondering if anyone else had these problems and if so how did you solve them?
Code: Select all
Compiling...
GroundCover.cpp
C:\ogrenew\Samples\ChatColl\src\GroundCover.cpp(604) : error C2039: 'setVisible' : is not a member of 'SceneNode'
..\..\..\OgreMain\include\OgreSceneNode.h(44) : see declaration of 'SceneNode'
C:\ogrenew\Samples\ChatColl\src\GroundCover.cpp(635) : error C2039: 'setVisible' : is not a member of 'SceneNode'
..\..\..\OgreMain\include\OgreSceneNode.h(44) : see declaration of 'SceneNode'
C:\ogrenew\Samples\ChatColl\src\GroundCover.cpp(646) : error C2039: 'setVisible' : is not a member of 'SceneNode'
..\..\..\OgreMain\include\OgreSceneNode.h(44) : see declaration of 'SceneNode'
Error executing cl.exe.
ChatColl.exe - 3 error(s), 0 warning(s)
-
- Halfling
- Posts: 74
- Joined: Tue Dec 17, 2002 11:57 am
- Location: Somerset, England
-
- Gnoblar
- Posts: 10
- Joined: Fri Aug 06, 2004 1:23 pm
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Without meaning to state the obvious; as the error message says, have you defined the material that your mesh is using?
Can you display the mesh normally, i.e. as a standalone mesh rather than by passing it to the GroundCover stuff. Nothing fancy happens with materials, it's just the vertex/index buffers that get re-jigged.
@ Borundin
Sorry for all the VC6 incompatibilities, I'm making a note of them and I'll try to clean up the code in this regard when I'm finished what I'm currently doing.
And yes, these could be new methods, I'm using 0.14.1 or Ogre.
Can you display the mesh normally, i.e. as a standalone mesh rather than by passing it to the GroundCover stuff. Nothing fancy happens with materials, it's just the vertex/index buffers that get re-jigged.
@ Borundin
Sorry for all the VC6 incompatibilities, I'm making a note of them and I'll try to clean up the code in this regard when I'm finished what I'm currently doing.
And yes, these could be new methods, I'm using 0.14.1 or Ogre.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- Kobold
- Posts: 32
- Joined: Tue May 25, 2004 3:03 pm
- Location: Montevideo, Uruguay
That would work, although releasing a single class under the LGPL is more or less painful to use, because it should be in a DLL/so of its own (or, at most, stuff every LGPL source in a DLL/so) because of the dynamic linking requirement.monster wrote:Erm, hadn't given it a lot of thought.
How about LGPL?
Oh, come onmonster wrote:I'm overjoyed that someone finds it useful, and I'm sure all enhancements will be gratefully welcomed by everyone!

-
- Kobold
- Posts: 32
- Joined: Tue May 25, 2004 3:03 pm
- Location: Montevideo, Uruguay
OK, here it is, GroundCover with orientation and scale baking.
The zip - http://www.mysterystudio.com/_groundcover.zip
The code -
Old code still works - the old add() method is still there, assumes scale = (1, 1, 1) and orientation = identity. Besides, using this new add(), setting vScale and qOrient is optional.
The result (with ridiculous parameters to show it works) -

The zip - http://www.mysterystudio.com/_groundcover.zip
The code -
Code: Select all
GroundCover::InstanceData* pInst = pCover->add("tree1.mesh", "tree1lowpoly.mesh");
pInst->vPos = Vector3(fX, fY, fZ);
pInst->vScale = Vector3(randomFloat(0.1, 1.0), randomFloat(0.1, 1.0), randomFloat(0.1, 1.0));
pInst->qOrient = Quaternion(randomFloat(0, 6.28), Vector3(1, 0, 0));
The result (with ridiculous parameters to show it works) -

-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Fair enough. As you can probably tell, I'm no expert on such things.[LGPL] would work, although releasing a single class under the LGPL is more or less painful to use, because it should be in a DLL/so of its own (or, at most, stuff every LGPL source in a DLL/so) because of the dynamic linking requirement.
So pick whatever license you like, and do with it as you wish! I'd recommend the use of the NLWSE* license.

Oh, and regarding your new version ... COOL!
* No License What So Ever
-
- Kobold
- Posts: 32
- Joined: Tue May 25, 2004 3:03 pm
- Location: Montevideo, Uruguay
I forgot. This uses a tiny modification in the engine (which I discuss in this post). I had no feedback yet so I don't know if I should submit it as a patch.
For now, you can just comment the line that doesn't compile (I think it says _big_mesh->setCastStencilShadows(false))
For now, you can just comment the line that doesn't compile (I think it says _big_mesh->setCastStencilShadows(false))
-
- Gnome
- Posts: 327
- Joined: Sat Jul 10, 2004 6:46 pm
- Location: Sweden
- x 4
Excellent! I'll try it out when I get home.
What I want to add though is the ability to "shear" meshes. I.e. grass will alway grow upwards. So you'll want to adjust the vertices along the y axis, but not the x and z. That way you'll have meshes that are both aligned to the ground and pointing upwards.
What I want to add though is the ability to "shear" meshes. I.e. grass will alway grow upwards. So you'll want to adjust the vertices along the y axis, but not the x and z. That way you'll have meshes that are both aligned to the ground and pointing upwards.
-
- Gnoblar
- Posts: 10
- Joined: Fri Aug 06, 2004 1:23 pm
Anyone send me yours hitree.mesh and lowtree.mesh? i haven't feat mesh. rzhou_sh_antispam@hotmail.com, remove _antispam. thanks
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
Continuous LOD can be implemented, but they require more vertex buffer thrashing than most modern gfx cards are happy with. Better to just generally increase the number of tris at each discrete LOD so that the transitions are less noticeable, or use vertex shader morphing to hide the changes (see Terrain for an example of that).
-
- Gnoblar
- Posts: 4
- Joined: Sat Oct 02, 2004 2:16 am
uh, I actually meant using instead of two hard parameters just one Mesh which holds all lod levels (for example generated by: )
(So I confused ProgressiveMesh with Progressive LOD)
it should be really easy to do but I will think about using and extending this class to make it more general, later.
Code: Select all
ent->getMesh()->generateLodLevels(distanceList,ProgressiveMesh::VRQ_PROPORTIONAL,0.5);
it should be really easy to do but I will think about using and extending this class to make it more general, later.
Last edited by asdfghu on Mon Oct 04, 2004 9:05 pm, edited 2 times in total.
-
- OGRE Community Helper
- Posts: 1098
- Joined: Mon Sep 22, 2003 2:40 am
- Location: Melbourne, Australia
Yes, you could do that. In fact, the current code adds the low poly mesh you specify to the high-poly one as a lower LOD. So if you wanted to do what you ask then you'd simply do the reverse; supply a single mesh as a parameter and pull the lower LOD version out of it to make the big static mesh. Kinda makes it less flexible though (IMHO) since you've got to bake the low LOD model into your mesh, whereas with the original version you can easily swap and change it as you like.
I believe that, typically, you wouldn't use generateLodLevels to create the low-poly versions anyway. Since that wouldn't reduce the poly-count enough. The trees I used in my example have around 150-200 polygons in the high-poly version and are replaced with intersecting billboards (4 polygons) for the low-poly version. I don't think any automatic polygon reduction algorithm, unless it was very very clever, would give you that kind of reduction.
I believe that, typically, you wouldn't use generateLodLevels to create the low-poly versions anyway. Since that wouldn't reduce the poly-count enough. The trees I used in my example have around 150-200 polygons in the high-poly version and are replaced with intersecting billboards (4 polygons) for the low-poly version. I don't think any automatic polygon reduction algorithm, unless it was very very clever, would give you that kind of reduction.
-
- Gremlin
- Posts: 157
- Joined: Mon Nov 11, 2002 4:21 pm
- x 3
Indeed, NO polygon reduction algorithm would transform an object to a billboard alternative. However, the number of poly's is less important than the number of entities, as pointed out earlier. So a way to (temporarily) bake a number of entities into a single mesh could be a good solution. 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.
-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
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
Better explanation here “Batch, Batch, Batch:” What Does It Really Mean?" : http://developer.nvidia.com/docs/IO/823 ... hBatch.pdf
-
- Gnoblar
- Posts: 4
- Joined: Sat Oct 02, 2004 2:16 am