Not Rendering Parts of a DIF

#1 I would think that it would be a rather major change, but you could look at the alpha's in DIF resource to see how alpha is handled and then work from there with an entity tagging system that you can turn on and off.

#2 OK, after a brief look at the interior rendering, I have an idea to try out...

I can do a ray cast from the player to the camera looking for interior objects... If I collide with one, then I get the surface struct for that interior using the face parameter of the RayInfo. I can then set a flag on that surface that it should not be rendered, or it should be rendered transparent.

That wouldn't be much code change at all... A new surface flag, a quick ray cast, and an if statement...

Does anyone see any problems with that approach? I don't think it would break anything, but this is just a quick glance at the code.

Eric Armstrong
www.trihex.com

#3 Eric, the easest way to do this - is to create a DIF with different LODs in it, and if you want to have a same DIF but without wall, on second LOD make this wall to have NULL texture. The collision will stay the same, and you can see through it. Read an articles on TDN regarding how to work with LODs in DIFs.

good luck!

#4 Bank...

That is a possible approach, but the issue with that is that what walls would be removed would depend on the position of the camera in relation to the player. So, the artist would have to create a different LOD for every possible camera position, which is what we were kind of trying to avoid...

Something similar to what you suggest is kind of my fallback plan if I can't figure out a way to do it programatically...


Thanks for the suggestion.

Eric Armstrong
www.trihex.com

#5 Ohh.. I missed your second post. That's completely different story then..

Hmm.. I think what you are trying to do will require a hard hack into interior-render code, but I can't call it "impossible". The another problem you can meet - portals. No one knows how Torque will handle it.
If this is client-side only (eg Rendering only), then in case you use portals you will not see some objects, as server is NOT about sending packets for needed objects.
The workaround here could be not using portals at all, but in case you in multiplayer - this can cause additional performance lags.

And, your idea with "flag" is somewhat interesting and I think it's possible to do, though I haven't played much with interior render code...

Anyway, keep us informed on the progress, looks like really interesting stuff do trying to do :))

#6 Another way (hiding walls) is to use StaticShapes for that, but then you will have a huge hit on collision performance. And this will not even require any source changes and can be easily done by scripts.

#7 Just to give everyone an update...

My initial test on setting a flag on the surface is working, somewhat. I think I have some conversion I need to do on the positions before casting the ray, as my initial test would remove the surface when I was above it rather than below it, so things are a little reversed. There were a couple of additional issues I ran into that I'll need to think through also.

1. As far as the engine is concerned, the geometry is still there, and it is still culling out faces behind it that it thinks will not be visible. The end effect of this is that if you are looking a things at a certain angle, the object will just disappear totally.

2. This technique will not work in TGEA. TGEA builds vertex buffers (actually one giant vertex buffer) for the interior geometry before the thing is even rendered, so while I can get the contact surface, I don't have a way to connect that surface to the vertices inside the vertex buffer. We are building a pack that will include this functionality, and want to provide a version of the pack for both TGE and TGEA, so this is big issue.

We are experimenting with another possible technique that should work in both TGE and TGEA. With this technique, the artist will actually texture the outside walls with a special "no render" texture. When going through the surface and rendering them, if we pull that texture, then we skip the rendering. This worked a little too well, as the test object simply went away completely.

I've got some additional tests I'll be working on today, and I'm encouraged by what I'm seeing so far and think I'll be able to get this working. The real big issue around this is getting it usable as a pack. I'm pretty confident that by putting restraints on how the DIF objects are created, that we could get them working for our game, but we want to put a lot of this functionality into a pack to help generate some intermediate revenue while we develop the application. With the pack, I want it to apply to as many situations as I can so that people can use it in many different game types rather than only something similar to what we are developing.

I'll continue to post here on what I find out from my tests, and look for an announcement about the pack and all the glorious things it will include in the coming weeks.

Eric Armstrong
www.trihex.com

#8 Success!!!!!

Not perfect at this point, but it is doing exactly what we want. Right now, what I essentially had to do was to tell it to render every zone, which would be a performance hit, but it does show that what we are trying to do is possible. And I know exactly what i have to do to get it to work, now I just need to make a cleaner implementation.

Here are a couple of images... The first shows the DIF object from an outside view... The DIF object is actually a fully enclosed box, but we are dynamically removing parts based on how they are textured. As you can see from teh first photo, there is no ceiling.


Now in the second shot, we are inside the DIF object, and instant ceiling...

#9 Very nice! But just out of curiosity, why would you want to do this? To improve visibility while in 3rd person view?

Tony