Game Development Community

DynamicCubeMap Documentation/Implementation mismatch ?

by Kirk Longendyke · in Torque Game Engine Advanced · 07/23/2007 (10:54 am) · 11 replies

Docs (pdf grabbed from tdn) :
DynamicCubemap
This is a flag indicating that the material is going to use a cubemap created by the scenegraph.
Dynamic cubemaps are updated frequently for very realistice reflections. They are very expensive
as a result.
Dynamic cubemaps only currently work for ShapeBase objects. To enable dynamic cubemapping
on those objects, the flag dynamicReflection must be set to true for in an object's datablock. The
dynamic cubemap is then rendered from that object's center every frame.
Script reference: dynamicCubemap = bool

edited for standard: beware teh sh1tty placeholder art disclaimer. (may cause bleeding corneas)

Implementation:
DynamicCubemap in fact bases it's reflection plane on the angle from the users camera to a straight ray, or somesuch... Not quite sure how to describe it short of dumping the whole chain on here (read here, also why no fix-submission along with this, I'm afraid), so heres a pic-set (we are talking dynamic here) after implementing a 3rd party rescource that implements a fixed camera:

reflection 1-
img71.imageshack.us/my.php?image=25225387uo9.jpg
location 1-
img409.imageshack.us/my.php?image=1bju0.jpg

reflection 2-
img409.imageshack.us/my.php?image=79016728oo1.jpg
location 2-
img409.imageshack.us/my.php?image=2bun8.jpg

reflection 3-
img267.imageshack.us/my.php?image=50206985zs2.jpg
location 3-
img267.imageshack.us/my.php?image=3bvl9.jpg

and finally,
aparent origin of reflection-
img124.imageshack.us/my.php?image=74999730zl2.jpg

Now by no means am I going to sit here and claim this is a showstopper, or anything like it. Just pointing out one of the mickey-mouse bugs that *might* have been a bigger deal to someone doing a bit more hefty project with all the eye candy (but then, started this back when the engine was still EA, and picked a simple subset of points we could hammer on precicely so we *could* nitpick/polish the thing. Mean time, cubemapping seems to do almost as good a job, so using that.)

Just a heads up.

edit: embeded links. knew i was forgetting something.
NextNext Thread
PrevPrevious Thread
More from Torque Game Engine Advanced


Torque 3D Owner Mark Dynna
#1
07/23/2007 (1:13 pm)
Kirk, GG forums don't automatically parse links so if you could (in the future) wrap those links in [url] [ /url] (that last one without the space between [ and /) it would make it easier for people to look at your images.

Secondly, I can easily see that the dynamic reflection thing got missed in initial development. GG seems to test things from a distinctly "FPS game" perspective, so it would be quite easy to miss that sort of reflection issue, since it only manifests when your camera is not directly behind your character in the "eye" position.

Now, would I like to see TGE and TGEA have less of an "FPS slant" to them? Sure, but that's a different issue. However, even if I don't like it, I have to admit that a "majority" of games being developed have an "FPS-style" interface to them. I also concede that GG can't test their engine in every time of game imaginable, so I suppose it's as good as anything to pick "FPS-style" and test towards that.

Torque Owner Kirk Longendyke
#2
07/23/2007 (1:19 pm)
Rgr, and fixed the links. Again, not so much of an unworkarroundable complaint, as a 'by the way, was tinkering and noticed...' observation, since it seems this'd be the place to post the mickeymouse, in addition to the major ones. Worst case scenario, I'll end up fixing it 4 or 5 games from now when theres less on my plate, and the games get more complex (and hence more's expected in keeping with the genre)

Torque 3D Owner Stephen Zepp
#3
07/23/2007 (6:31 pm)
If I remember correctly, the dynamic cubemap system came from the MBU "eat our own dogfood" implementation cycle, and I can see where some certain base assumptions were built in to the use case.

I'll bump it up for notify purposes, but as Kirk comments, it most probably won't get a particularly high priority.

Torque 3D Owner Stephen Zepp
#4
07/24/2007 (11:10 am)
We've been reviewing the images, and quite honestly aren't sure exactly what the issue is. I can see in the third image set that it looks like the reflection is possibly wrong, but it's really hard to tell without having the "big picture" of the rest of the environment.

Any chance of more accurate (word) descriptions of the issue, and/or more detailed images to demonstrate what you are seeing (as opposed to what we aren't sure we're seeing)?

Torque Owner Kirk Longendyke
#5
07/24/2007 (12:18 pm)
It's generating a reflective shot of the starting line dif wich is placed at a relative distance of (40,0,-180), and worldspace rotation of (0, 0, 1, 90) from a fixed-position 60/15 degree fov camera system that swaps between the pseduo-orthagonal view (the 15 degrees), and the over-the-shoulder-view (the 60).

removed total wild tangeant

edit: nope. see below...

Associate Manoel Neto
Default Studio Name
#6
07/24/2007 (12:38 pm)
The dynamics cubemaps aren't quite dynamic by default. There is a hack that makes them render only once, during their first update. Afterwards they'll retain the same image. You can verify this easily by moving the reflective sphere around in the TGEA demo. Its reflection won't update.

Open "gfx/d3d/gfxD3DCubemap.cpp". Comment this line out (It's right after the #include declarations):

#define INIT_HACK

Now, a warning: the performance will drop, probably a lot. But the last time I tested dynamic cubemaps was before the batching system, so I'm not sure how performance would be on the newer TGEA versions. Also, the skybox didn't render correctly on the cubemaps back then (it looks like it was only properly tested for reflecting interiors).

We ended up developing a custom solution (aka: putting together a huge hack) for real-time object reflections, since it was necessary for a past project. I can give you some guidance, but not the code itself (even if I could, it is unusable on post-batching TGEA versions).

Torque Owner Kirk Longendyke
#7
07/24/2007 (1:27 pm)
Yep. that fixed it alright. no real significant hit with the stock 
// render scene
      gClientSceneGraph->renderScene( InteriorObjectType );
mask. we'll see what throwing more at it does in a bit.
edit. yeah. gClientSceneGraph->renderScene( STATIC_COLLISION_MASK|DAMAGEABLE_MASK ); droped her rigth through the floor there. probably best to leave that as a case-by-case basis.

Torque 3D Owner Pat Wilson
#8
07/24/2007 (2:37 pm)
Just to jump in here. Dynamic cube maps are expensive. We did a priority-based updating scheme for Marble Blast Ultra. All Marbles needed dynamic cube maps, however with as many as 8 on the screen at once doing updates for each one, each frame was not worth the expense. The ones which are closest get updated once-per-2-frames, and the farther away ones get round-robin updating. I recommend poking at a solution like this.

Torque Owner Kirk Longendyke
#9
07/24/2007 (4:14 pm)
Quote:
Dynamic cube maps are expensive.

exponentialy so, actually, if youre talking rendering a surface that reflects a surface that renders a surface that reflects a surface that ... well, you get the point. IIRC the term used is the hall of mirrors recursion pitfall, or somesuch. Also, hate to poke at a sore wound, but... after adding masks back in one at a time to see what'd happen, the biggest framerate killer was atlas, actualy...

Torque Owner Kirk Longendyke
#10
07/24/2007 (5:18 pm)
Sorry for the bump, as well as going a bit off-topic, but ran across this lil side-issue in addition:

www.garagegames.com/mg/forums/result.thread.php?qt=58720

rather obviously going to be reviewing that end first, but just as a side check: the dynamic cubemap system *does* close on down once you kill off the GameTSCtrl(PlayGui), right?

Associate Manoel Neto
Default Studio Name
#11
07/25/2007 (10:08 am)
Test the performance with only one dynamic cubemap. Also try lowering its size (look for "initDynamic" and you'll find where the dynamic ones are created), since the default is 256.

I workaround is modifying the code so you can share a dynamic cubemap across different objects. That's part of what I had to do for dynamic car reflections: the reflection was rendered from the control object's position and shared among all other cars.