Rendering A LOT of things

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2

Post by Kencho »

Well, don't you think alpha rejection would be better for this than alpha blending? ;)
Image
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4

Post by Azatoth »

Yep, there's alpha rejection too. It's just that that specific texture and that specific mesh didn't look too good with only rejection.
Image
It's a devel version though, so there's a lot to do.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Cool! Tiptoe through the tulips!
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2

Post by Kencho »

Yep, maybe the effect is not that good after all with only rejection... but the frame rate grow a little, that use to be a good sign :)
Image
User avatar
Borundin
Platinum Sponsor
Platinum Sponsor
Posts: 243
Joined: Fri Oct 03, 2003 5:57 am
Location: Sweden
x 2

Post by Borundin »

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:

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)
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?
Image : Image
User avatar
bad_camel
Halfling
Posts: 74
Joined: Tue Dec 17, 2002 11:57 am
Location: Somerset, England

Post by bad_camel »

You could just checkout the cvs online (sf.net/projects/ogre) or checkout a copy of cvs.

The current cvs seems to have setVisible methods for MovableObject, SceneNode, Entity and a few others, not sure what they relate to, but it's prolly as you thought
rzhou_sh
Gnoblar
Posts: 10
Joined: Fri Aug 06, 2004 1:23 pm

Post by rzhou_sh »

compile ok, see nothing when run,

find some errors int Ogre.log

19:14:24: Can't assign material 1 - Default to SubEntity of GroundCover BigEntity because this Material does not exist. Have you forgotten to define it in a .material script?

anyone help me?
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

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.
User avatar
ggambett
Kobold
Posts: 32
Joined: Tue May 25, 2004 3:03 pm
Location: Montevideo, Uruguay

Post by ggambett »

Monster, what's the license of this code? I'd like to extend the GroundCover class to handle multiple LODs (at least 3) and have add() accept a quaternion as well as a position and a mesh, among other things.
Gabriel Gambetta
Mystery Studio - Home of Betty's Beer Bar and Wild West Wendy
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Erm, hadn't given it a lot of thought.
How about LGPL?

I'm overjoyed that someone finds it useful, and I'm sure all enhancements will be gratefully welcomed by everyone!
User avatar
ggambett
Kobold
Posts: 32
Joined: Tue May 25, 2004 3:03 pm
Location: Montevideo, Uruguay

Post by ggambett »

monster wrote:Erm, hadn't given it a lot of thought.
How about LGPL?
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:I'm overjoyed that someone finds it useful, and I'm sure all enhancements will be gratefully welcomed by everyone!
Oh, come on :) Your stuff (be it code or posts) is always extremely useful and a great value for this community.
Gabriel Gambetta
Mystery Studio - Home of Betty's Beer Bar and Wild West Wendy
User avatar
ggambett
Kobold
Posts: 32
Joined: Tue May 25, 2004 3:03 pm
Location: Montevideo, Uruguay

Post by ggambett »

OK, here it is, GroundCover with orientation and scale baking.

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));
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) -
Image
Gabriel Gambetta
Mystery Studio - Home of Betty's Beer Bar and Wild West Wendy
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

[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.
Fair enough. As you can probably tell, I'm no expert on such things.
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
User avatar
ggambett
Kobold
Posts: 32
Joined: Tue May 25, 2004 3:03 pm
Location: Montevideo, Uruguay

Post by ggambett »

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))
Gabriel Gambetta
Mystery Studio - Home of Betty's Beer Bar and Wild West Wendy
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4

Post by Azatoth »

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.
rzhou_sh
Gnoblar
Posts: 10
Joined: Fri Aug 06, 2004 1:23 pm

Post by rzhou_sh »

Anyone send me yours hitree.mesh and lowtree.mesh? i haven't feat mesh. rzhou_sh_antispam@hotmail.com, remove _antispam. thanks
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Just use any two meshes of your choice. Ideally one will be a high-poly model for "close up" viewing, and the other will be a low-poly version of that model, but it doesn't have to be.
asdfghu
Gnoblar
Posts: 4
Joined: Sat Oct 02, 2004 2:16 am

Post by asdfghu »

how about progressive lod meshes?
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Ogre doesn't support progressive LOD meshes (AFAIK) - there's been some discussion of this elsewhere - so, no.

It wouldn't be a huge stretch to add more than two levels of LOD, but you're going to start chewing up huge amounts of memory for all the vertices.
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 »

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).
asdfghu
Gnoblar
Posts: 4
Joined: Sat Oct 02, 2004 2:16 am

Post by asdfghu »

uh, I actually meant using instead of two hard parameters just one Mesh which holds all lod levels (for example generated by: )

Code: Select all

ent->getMesh()->generateLodLevels(distanceList,ProgressiveMesh::VRQ_PROPORTIONAL,0.5); 
(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.
Last edited by asdfghu on Mon Oct 04, 2004 9:05 pm, edited 2 times in total.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

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.
User avatar
dennis
Gremlin
Posts: 157
Joined: Mon Nov 11, 2002 4:21 pm
x 3

Post by dennis »

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.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4

Post by tuan kuranes »

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.

Better explanation here “Batch, Batch, Batch:” What Does It Really Mean?" : http://developer.nvidia.com/docs/IO/823 ... hBatch.pdf
asdfghu
Gnoblar
Posts: 4
Joined: Sat Oct 02, 2004 2:16 am

Post by asdfghu »

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?