Static meshes

#1 I would be pleased as punch... so to speak... if support for static mesh type architecture was possible. I've been mapping and modding for UT2003 as well, and I've grown fond of how that system works. If anyone knows anything about this please tell!

Thanks!
Dan

#2 Hardware brushes?

You'll have to give us a clearer definition. Currently you can use "static meshes" which are essentially just 3d objects that you can place in the scene by going to the editor and choosing one and dropping it in the scene.

Is there another type?

Phil.

#3 @Phil,
I try to bring a little bit light (or better shadow ;-)) in this issue.
On following PiC you see some of the mystical U-Engine StaticMeshes.
The green marked objects are StaticMeshes.
This meshes are almost like TGE meshes with one big difference, the U-Engine use also this meshes for lightmap calculation.

So you can use much more of them with shadow, the are like highdetail Interiors.

Oki this would be realy a big issue if the TGE could use special StaticMeshes where the shadow is already calulate at the relight of the mission.

Hope i don't write to weird and you understand what i'm mean

- Sven

[edit]offcource the image link ;-)[/edit]

#4 Very easy to add, afaik.

#5 Unless something has changed in the last 4 months or so in HEAD, Torque's static meshes are ignored when it comes to lightmap calculations. There are ways to turn on shadows for static meshes, both dynamic and pre-rendered shadows, but it requires a little code hacking in order to do it.

A search for static and shadow would probably return quite a lot of info on this.

#6 Hang on there Ben and David, hold your horses !! :-)

Static meshes is the number one reason to why UT 2k3 can handle remarkably higher polycounts compared to its predecessor (any many of it's competitors too(ooh what a shameless plug!! trust me, purely non-intentionall)).

This is the UnrealWiki cut-and-paste:
A static mesh is a type of mesh which is cached into video memory, and so can be displayed many times with little extra overhead. "Static" in "static mesh" doesn't mean "doesn't move." In fact, it can be moved, rotated, retextured and scaled (even disproportionally) in realtime. The "static" only refers to the fact that it can't be animated. Static meshes are a list of vertices stored once in the video memory (as opposed to "once per frame"); when the static mesh is to be displayed on the screen, the engine only has to tell the video card where (and at which size, rotation, and with which textures) to do it.
:end of snippet

Example, if I where to build a nice hallway BSP-stylee it would generate lots of polys for the 3d-engine to calculate. In the case of static meshes I draw a simple cube, dress it with static meshes and save. When the 3d-engine reaches this part it basically pretende the mesh is there and lets the 2d pipeline render it (what the GFxCard actually does best), well you have probably figured it out by now and I should stop blabbering .....

You could also check out the UnrealWiki for mor info. Click Here

#7 All they're really saying is that they keep the static mesh in a displaylist, VBO, CVA or similar structure.

As Ben said, easy to add.

#8 So they are non-animated meshes implemented as Vertex Buffers more than likely.

#9 I believe Melv May has done some work in this area with his "instancing" of geometry. Not sure if it ever made it into the HEAD though...

#10 Jarrod > mm, yeah about.

Barry > Ohh, any concrete results ??

Mark, Ben >

hmmm, okey.
The more I think about it I realize that this is above my head, I mean, I know how to store data in specific memory areas via C++ but I don't have a clue how to save to videoram.. (I assume this goes into engine source C++)
As I said, I only have some experience.

But if you say that it is easy to add it, I will let my teammember have a look at it! :-)

BTW, afaik <-- what does it stand for ??

#11

Quote:I know how to store data in specific memory areas via C++ but I don't have a clue how to save to videoram

The best way is probably the GL_ARB_vertex_buffer_object extension, which you can read about here.

If your advanced teammember knows C++ and OpenGL, it should pose no problem.


AFAIK = As far as I know.

#12 @Jorgen: My bad, in Torque "static" means just that -- a mesh that isn't (normally) a moving object and therefore skips a lot of the specific moving-object scene handling. But what you're talking about is a standard read-only vertex mesh. I agree with Ben, this shouldn't be all that hard to add.

You shouldn't have to do anything special in your code to copy the vertexes to video RAM. It's just a matter of finding out what OpenGL calls it takes to make the vertex buffer read-only and non-discardable, then set flags on objects that need this special handling for the scene renderer. OpenGL should take it from there.

I'm more versed with VBs in DirectX, so I can't tell you off the top of my head how to accomplish this in OpenGL.

#13 I am taking courses in OpenGL in a year (must remember this at that point).

I dont mean to sound like wining kid here, but in other tech (u2e) this has dramatically raised performance and visual quality and if it is easy to incorporate.. why hasn't it?

#14 I've done it before on the .dif objects.

It improved framerate a bit, but not as much as you might think it would.

It's really only helpful if you're either multipassing geometry a bunch of times (which I do in my modified torque) or using the same mesh over and over.

And even then, you have to be bottlenecked on geometry processing. A lot of games are going to be limited by fillrate or CPU side issues.

#15 Oops, I am to tired to see straight, didn't mean to sound like a 5 year old, sorry :-)

Mark >
It's really only helpful if you're either multipassing geometry a bunch of times (which I do in my modified torque)
this is exactly what I want (in a outdoors env.), is it possible to get some pointers ??

thx all for your inputs !!
If anyone happenes to find a quick way of implementing this, keep me posted please !!

#16 Doesn't the foilage replicator take advantage of this? Not sure if it's Melv's or someone elses, but I swore I saw either a message on here, or perhaps in the source code, mentioning doing that very thing.

#17 David > I've bookmarked that resource but haven't had the time to examine it yet but what I am working on would (I hope) be greatly helped by a efficient routine implementing some of the above techniques.
Altough at the moment it only seems like Melv has implemented this on a billboard level and is working on adding a soultion for meshes.

Mark > Is this what you've been adding to your modified Torque (some sort of Replicator ??)

#18 No, not a replicator. I was experimenting with some code that runs an extra pass per visible light. I added in some VB classes and converted the non-animated entities to use 'em because I was concerned that I was retransforming geometry too many times per frame.

Pointers? My advice is to code up a good general class for vertex buffers (You can look at code like Ogre for examples, but don't copy and paste - it's GPL). For the .difs, it's as simple as ripping out the code that determines visible faces and so on and substituting a VB per portal zone. The dts are similar, but you won't really be able to extract benefit out of a static VB for animated meshes if you don't want to use vertex programs.

Good luck!

#19 Or you could just use TSStaticShape and do the hack to get it casting shadows.

#20 Well, yeah, but Jorgen was specifically asking about storing the vertex data in video RAM.