Models with texture sounds

[DIO-SVK]

Hi all.This topic is all about idea of different material behavior in models by their textures. I know that others think that this is not good or useless idea.
As a mapper in valve´s Hammer i know that i can´t make huge maps with high detail like in game S.T.A.L.K.E.R with their X-ray engine.
There is more than one thing i or we like in their engine.The dynamic map shadowing (day and night) ,Enormous huge maps ,high detail buildings/objects and this material thing that this topic i started for.

Only problem in Stalker is that their engine don´t have brush based (hammer based) triggers and Entity´s with their Inputs and Outputs.
and is too complicated for normal person to make maps for their engine.

I found in Stalker that all geometry in map are separate objects that they don´t have prop data like in source engine but the object have separete textures and their textures have material propertiles like textures for hammer have surfaceprop properties (gravel,metal,glass...).

So its possible to make object or objects with separate textures that have different surfaceprop properties?
(Object that will act like textured brush based geomety in hammer)

Why i want this kind of thing?

Because it will be better for hammer mapers to make more detail maps.
Imagine.Create district like in Stalker Call of pripyat.and not only one textured brush per building in hammer geometry but with all details.

Windows with ledges and handles, doors with handles ,balcony...using models.

The bad thing i dont like in source engine is that every model have only one prop data -> surfaceprop properties per model.
So if i make wooden bench with metal brackets the model will only sounds and act like is created by one material that means = wood
or if i make building with all details the model will only act and sound concrete even if i shoot window only concrete sound.


So enyone have idea or method how make this upper idea real??

Sorry for my bad English
And please reply

Edit: I hope i post this topic to right section.

[Jordash]

I'm not sure what your are trying to say in the middle of your rant, but concerning the wooden bench problem:

The common way around this is to divide the model into two models during the compile process, the brackets as one model, the wood as another, then place both models in the same place in hammer. The bench and brackets should line up, but the metal will be like metal and wood like wood. Note, it only works for static models.

[DIO-SVK]

What i try to say is that if you ever play one of X-ray engine = Stalker game you know all geometry in game is model based not brush based like in source engine and in stalker models don´t have surface properties.Only textures have them.
So if you shoot building to the window the window will act and sound like normal window.
And that building is one object textured not with one texture/skin like in source engine but textured like brushwork in hammer.
So i want if is possible somehow make models that will act and sound like brush work even in prop_phys not only in prop_static
And thanks for reply

[Mr. Happy]

Sry but I dom't think this is going to happen. Materials also can contain a $surfaceprop value but that is overriden by the props prop_data.

[Sathor]

As Source can handle several thousand prop_statics, you can create several models for one object. If you have both considerable amount of metal and wood surface, you might consider making one model containing the whole metal stuff and another for the wooden stuff.
Not the ideal solution, but a way to work around the problems.

[DIO-SVK]

First of all thanks fo your helpfull answers.I was thinking if is possible to skip $surfaceprop value in qc file to have this material thing or somehow re-made material system in script folder (surfaceproperties.txt or prop data.txt)
And Sathor source can real handle massive amount of prop_static??

My problem is that i can´t make higher detailed buildings with brushwork because i fast hit map limit and for vvis.exe ou.. 3hours to compute visibility.. and making all of the fancy stuff (3d windows with ledges...) -> prop_detail give me the (Too many t-junctions to fix up!) problem.

If i make fancy building with 3d windows... (brush work) as in images below i make only 3 of them and map limit is full.



So i optimalize brush work and make buildings like valve == one brush per texture so this is result.

but something missing .... ou i know that fancy stuff...

I try make the fancy building made with brush work as model but first i discover that hammer has limit of 24576 polys per model and after error that shows me that limit hammer´s render crash and only black screens
And second this material problem (windows, doors, doorframe´s and window frames act and sound´s as all other geometry of model that means == concrete)

i can separate fancy geometry of windows doors and doorframe´s...

But? does source can handle all that prop static for all these buildings in image??


and that´s only half of map that i want to make.

[Groxkiller585]

Trying to make each BUILDING prop_static will have too many vertices, but if you split the buildings into 16th's and compiled models for each bit, then pieced them together in hammer that would work. Source can handle literally 1000's of static props so no worries on how many you use.

[tron00]

Trying to make each BUILDING prop_static will have too many vertices, but if you split the buildings into 16th's and compiled models for each bit, then pieced them together in hammer that would work. Source can handle literally 1000's of static props so no worries on how many you use.

I had some pretty complex buildings and I noticed using Propper, it simplified the collision mesh nicely.

Sry but I dom't think this is going to happen. Materials also can contain a $surfaceprop value but that is overriden by the props prop_data.

I've always wondered about that. Thanks. So, I guess it's a waste of time then to bother with the surfaceprop value in model VMTs, then.

[Jike]

and what if you just leave away the prop_data in the qc?

will the $surfaceprop in the VMT stay dominant then?

[Jordash]

If you leave it out, it will be default, which is concrete I think.

[DIO-SVK]

If you leave it out, it will be default, which is concrete I think.

Nope model act like plaster or plastic same sound

It´s funny that my big building sound´s like plaster model (everywhere)

And tron00 how i make fast and cheap collision mesh from reference model that will be not expensive like reference model but still full collide??

I am using XSI 7.5

[tron00]

Sorry, dude.. I'm pretty good at decompiling, reskinning, and fixing existing collisions, but I'm still a newb. I'm not far enough to know how to do that, yet.

[DIO-SVK]

Thanks tron00. I see you like to edit the props your way .For me making geometry is task about 5-10 minutes in XSI by polys or in Hammer by brush work .But 1hour wasted time in UV mapping editor (XSI 7.5) makes me mad .I don´t want to say i hate texturing.I like hammer´simply texturing but not complicated XSI UV mapping.Oh i know that HL2 creator´s want to simplify the work with models by one UV texture per model.But why they make even one prop data per model.I try to split model like Groxkiller585 but still i think that must make collision mesh for both props not just for one and i was hoping if is something to simplify the collision mesh creation.I hate make collision mesh from primitives all over again.

[Groxkiller585]

Trying to make each BUILDING prop_static will have too many vertices, but if you split the buildings into 16th's and compiled models for each bit, then pieced them together in hammer that would work. Source can handle literally 1000's of static props so no worries on how many you use.

I had some pretty complex buildings and I noticed using Propper, it simplified the collision mesh nicely.

It did not simplify it - it collapsed it. My guess is you did not func_detail some of the details of the model and you went over the collision vertex limit. Therefore Propper cascaded the collison model and made it one big convex hull. Now on a square building it's hardly noticeable but on pipe clusters or even door frames you'll have problems because then you cannot walk through (ONE convex hull piece means your model is "bubble-wrapped" in the collision model, it looks very ugly.)
if you wish to manually make a collision model for Propper, func_detail the whole building then make brushes textured with tools/invisible or tools/nodraw for the collision hull. This is almost a must to optimize the model.

[tron00]

It did not simplify it - it collapsed it. My guess is you did not func_detail some of the details of the model and you went over the collision vertex limit. Therefore Propper cascaded the collison model and made it one big convex hull. Now on a square building it's hardly noticeable but on pipe clusters or even door frames you'll have problems because then you cannot walk through (ONE convex hull piece means your model is "bubble-wrapped" in the collision model, it looks very ugly.)
if you wish to manually make a collision model for Propper, func_detail the whole building then make brushes textured with tools/invisible or tools/nodraw for the collision hull. This is almost a must to optimize the model.

Man, I learn something new every day. Thanks for the tip. I remembered reading you only wanted to func_detail parts that you wanted to be non-solid. I can see where doing it this way give you a lot more control over the collision mesh. Thanks.