Game Development Community

Info on addmaterialmapping changes/use

by TheGasMan · in Torque Game Engine Advanced · 06/23/2007 (9:40 pm) · 24 replies

I apologize if I overlooked something...but I spent about 3 to 4 hours reading and testing this.
I would like to add sounds to a material/texture mapping etc.

Any help is appreciated.
Thx


//==
Off Topic Question:
@ TSE's milestone3, 'addmappingmaterial()' was removed (( http://www.garagegames.com/blogs/5030/8121 ))

Was this replaced or added back in ?
...I am also curious why it would have been removed if it wasn't broken.
It seems to be broken and undocumented now.
Page «Previous 1 2
#1
06/25/2007 (10:13 pm)
I'd love for any information / thoughts on this as well.
#2
06/26/2007 (7:50 am)
I don't think it was needed anymore. A Material is mapped to a texture when it is created using the Material's "baseTex" field or its "mapTo" field.
#3
06/26/2007 (8:31 am)
I think they're referring to the mapping of a sound to a material, for different foot step sounds on varying terrain and the like.
#4
06/26/2007 (9:52 am)
@Tim: Yes, thats it. No matter what I do it doesnt work. Any help on this would be appreciated.
#5
06/27/2007 (1:41 pm)
Staff ?

Also, is it possible to get the 'materials.cs' files from the TSE demos ? (dojo and car) ...I would like to see what was implemented in 2004 and then changed. This will help me to learn to think like you guys as so I can help myself decipher future issues/questions by myself, heuristically.

Thank you... +BTW I have 2 accounts here
#6
06/29/2007 (3:13 pm)
I see posts asking the same type questions that cover almost two years it seems. Is this broken.. is there a way to fix it or a work around, and/or will this be fixed in the next release?


The silence is deafening... :(
#7
06/30/2007 (12:54 am)
How about an SVN changelog from the time of around Milestone 3 ?
This would help all of us, possibly, sort the issue...but I do doubt that would be available TBH.

Anyways....
Did GG fire the guy or did he quit ? Brian Ramage, where are you and why are you hiding form this ? ...2 years!
...all we want are a few clues toward the fix or an explanation of how to use the material in it's "new" fashion as you so proclaimed.

[[bad taste starts to grow in mouth]]
#8
06/30/2007 (7:50 am)
I'm fairly certain there is currently no support for the sounds per material support in TGEA. You'd have to rig it up yourself.
#9
06/30/2007 (1:21 pm)
Thanks J.C. for your reply.

This may very well be true, and if so, I'm looking for an official response of some kind stating this, or plans/reasons/methods in reference to the issue.
#10
06/30/2007 (3:49 pm)
After a week of looking into alternate methods for doing this type of thing, I'm afraid I'm going to have to add my name to the list of folks that need some kind of info on this... :/ It's really a simple pair of questions: How do you go about adding nonvisual data to a material, and how do you then refference it?
#11
06/30/2007 (9:14 pm)
My best guess would be that because of the way atlas clipmaps work you couldn't really do footstep sounds based on atlas materials without a heavy overhaul. They may have removed it thinking of another solution in the future that never happened.
#12
07/01/2007 (5:26 am)
Pardon if this post seems rude...I do not mean to offend or insult anyone...

Our team: we have found 'commented out' code in a few areas concerning this specific issue.
-> However, full knowledge of this "item/situation" is ideal to loads/alot of developers. IMO, fixing or explaining the changes from the old code base would be 'grand'. Was it TGE 1.4 or 1.5 that was used as the base for TSE milestone3 ? I read that the code works in 1.5 but I am not positive that I should believe such a thing. Very mind boggling TBH.

We could recode the entire "idea" but I think this fundamental engine item should work without issue whether or not 2 years has 'come into play'.
-> My team can hardcode the sounds, re-write that code entirely or do what we need but such a simple thing to this staff of GG coders should be explained to the licensees....even in a manner that stipulates "we are sorry it is broken, here is a bit of help"..."here are the files we adjusted to change this code...blah blah blah.

...something, even 'anything' would be good.
A few memories of the changes to the code or "just the memories" of a general idea of changes would be incredible!!!

We would like a fix and TBH we would like it before we re-write something that you may fix soon. Please save us our wasted time and let us know something about this situation.
....is it on "top " of the list or is it something that won't be addressed for another year ?

let us know plz.
Thank you
eb
#13
07/01/2007 (10:48 am)
This isn't a topic I'm all that familiar with, so most of this is based on reading code on a Sunday morning.

'addMaterialMapping' was a console function you had to call in order to add a mapping. You no longer need to call it (although it is still there if you look for it) because the material will automatically set up the mapping. Of course, that won't automatically add a sound and color, so if you want to do that you'll want to call addMaterialMapping directly.

In TGE there used to be a lot of code that called this mapper in order to get footprint colors and sounds from a material. This is not called in TGEA, as you noted. But that is because it has been disabled in TGEA from the start -- i.e., the engine started by disabling a ton of stuff and then slowly adding it back in. Footprints weren't added back in till last fall, at which point they were added in with the decal manager rather than the way they used to. For some reason, the old code is left in there commented out. (Grrr). So new code ignores material mapping while old code used to use it. But that doesn't mean material mapping code is broken (I don't think it is because we used in pretty much as is for MBU 360).

BTW, material mapper isn't needed to do this type of thring really. You could just as easily set up your own hash table and be done with it, adding whatever information you wanted instead of relying on what the engine provides. In fact, that would be faster since the material mapper doesn't hash, and instead performs a linear lookup.
#14
07/01/2007 (12:38 pm)
Thanks for your answer Clark.

I'm very new to TGEA but had a somewhat deeper look at this issue this weekend. Maybe I didn't get deep enough into the code but what J.C. Smith said above (keyword Atlas) makes sense to me and would maybe be the reason why I didn't get the mapping to work.

For me it looks like something like the code in Player::updateActionThread() which is commented out is needed to read and play assigned sounds. For my understanding MaterialPropertyMap (which should have stored the material<-->sound assignments) doesn't work with Atlas any longer because Atlas (clipmapped terrrain usnig a single large texture) needs no table that can be queried for texture position information.

Sorry Clark, but I doubt you used the TGEA code we have without modifications. I can't imagine FPS games wihout material<-->sound mapping so I hope GG will clear things up.

Thanks

Stefan
#15
07/01/2007 (3:12 pm)
Since this is the public forums, I'll forgo tossing in the usual partially working code, but I can say one of the more promissing experiments i started conducting after a chat with Mat Fairfax ( at 7am no less, so lets not hear the 'they don't give a shit' complaint again) this end for a *generalised* solution to the issue involved the triray func from

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

at minimum, it'll let you get the material mapped to either a dts, or dif derivation. Still working on a generalised terrain version, as well as hooking in particle emmitter, and sound lookups, but it's progress of a sorts... not as good perhaps as something cooked up by someone with more face time with the engine. Long term, I'll be the first to admit that honestly, I wouldn't call it more than a band-aid, as there's no way to look up embeded data serverside for damage modification ect, but for *purely* clientside activity... (hell, probably still a waste of time, but better to try than take no real action than whine about your lot in life)
#16
07/01/2007 (3:55 pm)
Hello Kirk,

While I have no idea what your talking about with the "they don't give a shit" comment, (since no one in this thread has said this) I appreciate you taking the time to respond. At least for me, it has nothing to do with "them" caring or not.

I personally, am attempting to find out why the snipets were removed / commented out originally, and to what conclusion. A person does not do this unless it solves and issue, or plans are in the works for a different method. So.. again, was somthing planned, is still planned, or was it's use hindered for some other reason.

I'm not trying to speak for everyone else here, just for me. And thank you for the link Kirk, I will review it asap.



edit: Forgot to say thanks clark for your attention to this, it is appreciated.
#17
07/02/2007 (1:11 am)
Thank you for that information Clark Fagot. ;)
//-
Also, I 100% agree with the above post, perhaps kirk was grumpy/groggy when he posted ?
...I often read posts where someone "reads-into the written words" rather than "just reading the written words". Forums are notorious for that kind of activity.
#18
07/02/2007 (1:48 am)
Lil of both, and apologies for same. gonna see if i can't roll something up for folks by end of next week. (though since it'll be code heavy, gonna have to take it into private)
#19
07/29/2007 (10:23 am)
Update: There are no plans by GG to fix this issue...this is known by licensees as of this date.

Subject to change (of course)....but the lot of us doubt it will be fixed since it has been 2 years past the promise.

Plz do not attack me.....I am ONLY stating FACTS.
http://www.garagegames.com/blogs/5030/8121
#20
07/30/2007 (2:14 pm)
There's really no need for GG to 'fix' this, as it's extremely simple to do. The Atlas clipmap situation doesn't really apply here, as you don't care about the other levels, only the one you're standing on. You know your position, you know the level of atlas detail. Just ask the alpha TOC what your current value is, and you should then know the type of terrain you're on. There's your footstep puff color. Add a new value to the material definitions to contain either the sounds, or perhaps simplify it with just a material type enum, and play an appropriate sound for that.
Grabbing this info from dts/dif is actually the difficult step. Tom Spilmans ideas as they relate to dynamic texture/GUI might be the way to go; personally I think another method might work better. If you've followed the material/texture code down through map2dif, you've probably realized the entire trouble is that whats rendered isn't what actually hit. You're hitting a convex (think collision box), which exists _with_ the rendered texture data, but there is no bridge. Ideally, (imho) when we are creating these convexes in the exporting, we need one additional variable, the material type. Then any raycasting would know a little about what got hit, instead of just 'where'. This really shouldn't take more than an hour or three to add; I personally have held off as I wanted to see where constructor's exporting was going, and whether or not I'd be able to tweak it. (Can I have the source, please? :))
Page «Previous 1 2