Baked ambient occlusion

#1 None of the torque model formats support multiple UVW channels phil. So unfortunately you will have to use the same UVW data set in the first channel to handle any/all bitmap and pixel shader effects that you plan to use (just like how the normal map, glow/emission shaders and multiple other pixel based shader effects work in torque).

Logan

#2 Thanks Logan, that confirmed something for me. I was digging in the engine and found the hard limit on UV sets.

I'd originally planned on just modifying that to support multiple sets of UV's. But realised the exporter wouldnt then export.

I guess I'll go to plan B and look again at FBX.

#3 Well you could extend the DTS format and the exporters to do the job. Its been something that a lot of teams have been asking for and requiring to more effeciently use video memory with pixel shaders so the demand is definately there from a lot of teams.

Personally this is one of those key items that requires a bounty and should have been done a long long long time ago.

#4 Fixing the exporters is definitely the _correct_ way to fix this, but if you don't feel like it you can probably cheat a bit if you really wanted to... Export several DTS files with the same mesh and load just the UVs from one of the files? Maybe have the mesh duplicated in the same DTS and throw away the mesh data from the clone? It would make it a bit messier "tools pipeline" wise, but not too bad.

#5 Magnus: thats kinda sneaky.. I like it.

But not exactly the most user friendly way of doing things though.

I'd rather do this properly.

Having said that, FBX would be nice, but I doubt I could realistically take the time to do a full skinned mesh handling implementation. I'll have a look at the exporter code first. Although I'm a bit wary of doing that because there are already a ton of exporters that dont work as well as others.

Maybe FBX is the only really logical route.

#6 Phil, we are using baked occlusion on all our characters and small objects the results are very good, even with mirrored textures. We simply merge them with the base texture, no need for another texture or UV layer or code changes.

But of course this approach is useless if you need tiling textures.

#7 Wow, Manoel. Sounds like GG needs to flip some contract work your way....

#8 Manoel, it just so happens I do need tiling textures. Plus, it feels a bit wasteful to have a full res ambient map considering it could be roughly 1/4 of the normal texture res and still look good with a bit of filtering.

I just think that its a rational thing to want multiple UV's. I'll have to look into how I can hack it a bit.

#9 This may be a stupid question, but are multiple UVs even required? Couldn't you do ambient occlusion through a shader?

#10 Matt, doing real-time ambient occlusion would be very expensive, while baked ambient occlusion works in the same way as a lightmap (but it's not dependent on light positioning).

I see your problem, Phil. Actually, we had the same problem here at my company: we urged for better baked lighting solutions, and we have invested quite a few months in developing a custom solution for that. It's rewarding, but takes quite an investment (more than I was expecting).

I'll suggest a last workaround before you either start modifying the DTS format or rolling your own renderable class: tile of the diffuse/bump textures by scaling their UVs, while using the original UVs for sampling the occlusion map. You'll have tiled textures, but not much fine control over them (since they depend on the occ map UV coords). I used that trick years ago when working with Macromedia Director 3D (which didn't directly support multiple UVs either).

You can do a quick test by writing a custom shader, or do a more robust implementation by adding new fields to the material class and creating one or two new shaderFeatures for the shaderGen to do the job in the procedural shaders.

#11 The thing is, actually adding multiple UV's into TGEA wouldnt be that hard. Whats hard, is that you'd then have to write exporters for all of the various apps to make it worthwhile.

I've long been saying that I think its a better approach to actually load a "standard" file format and then perform some kind of local caching into an intermediate format if thats required. My ideal art pipeline would allow artists a lot more leeway and then have validation/checking tools seperate to that which take input in the form of source art and produce a report on any insanity in it. Rather than exporting from an app via an export interface, because of all the issues with exporter support.

There really has been a problem with my approach in that there wasnt a single format that supported everything one would need. 3DS support would be ok, but it is very limited. Likewise many other formats. But the advent of things like FBX and Collada give me hope that now is maybe a good time to look at that issue again.

A compromise would be a "DTS factory" which would take as input multiple file formats (3ds, obj, FBX or Collada) and would spit out DTS's (or a useful error report). But I'd rather have that as part of the loader process really, rather than an intermediate program.

#12 Going to a single, unified import program sounds like a good idea. Keep in mind that Torque is attractive to many indies because it supports low-cost art sourcing programs like Blender and Milkshape.

#13 Sure, but given the support burden for keeping all those exporters up to date with new features (or hell, even having the existing features work), isnt cost effective.

If there were a common format amongst these tools then fine. But otherwise you lose something.

Having common formats handled would surely be better (for instance .3ds and .obj would work for blender and milkshape surely?).

The point is to not have to write exporters. But... its definitely not the only way to crack this particular nut.

#14 You're on the right track Phil. The best bet is using FBX and/or Collada as "source" file format, since you don't need to worry about writing exporters for those (but there aren't nay Blender FBX expoters, I fear).

That's what we're using here at work to replace Interiors and TSStatics, but we didn't think of using it as a ticket for modifying and expanding the DTS format like you did. That's a good idea, and might be easier to do than what we're doing (replacing interiors is quite a task since we need to implement our own culling and collision solutions, as well as rendering optimizations.)

You could put the FBX/Collada to DTS converting functionality directly inside the Torque source in non-shipping builds, and "compile" fbx/dae files into dts files in a similar fashion Torque compiles scripts into dso files. In a shipping build, just remove the converting capability using defines (or leave it there if you want to support user content).

#15 I did think of that. Basically cache the intermediate files as .dts..

It makes sense to me, but I dont want to do the work!! :) hahahaha

#16 Just a word to the wise there before you get all giddy Phil. There are a lot of problems with the FBX and Collada (DAE) formats with regards to serious bugs and annoying nastly little feature problems due to how various developers have implemented import/export modules. So if you do anything like this you will have to spend a lot of time dealing with these little nuances in your converter application.

#17 Yeah, I already did a review of the collada stuff and saw that lots of features are missing. I also did some tests with FBX using the current discreet SDK and managed to get it to crash when reading an FBX file exported from max!!!

so yeah, not under any illusion that its a perfect solution either.

But whats the alternative?

#18 Sadly there really isn't one unless you want to make up a model format yourself to hold all this data.

#19 Well, you still have the tools problem. Who owns and updates the exporter? The trouble is, I just dont think anyone has time or money to really support exporters.

I figure both the FBX and Collada formats have more sustainability, even if neither is perfect right now.

#20 @Phil - A buddy of mine is doing some ambient occlusion in his engine (check out the video as well). I'll question him about how he went about it.