detail textures + skyboxes

[Glorfindel]

How feasible is it to apply detail textures (higher resolution textures applied with an alpha layer or 50% opacity to the current textures) to maps? Is it possible to do it without recompiling every map?

Also, how high can the skybox .tgas go in terms of size? I think a lot of maps would benefit from higher skybox resolutions.

Is bloom possible to put in the mod? I know several HL mods did it.

Just some thoughts I had. I'd be willing to pump out a lot of detail textures and skyboxes cause I think they'd make the engine feel a bit comfier.

 

[The Man In Black]

We're working on Bloom >_>

 

[J-M v2.5.5]

Bloom mod wooo!!!1!

 

[jon50559]

I agree with J-M on the bloom.

Detail textures sure can be put in without recompiling the map.
But to use detail textures you need to enter EVERY TEXTURE'S NAME you want to use the detail textures on into a text file associated with the detail texture you want. In short, a very tedious and painstaking process, for hardly any gain (and I think you'd need to edit an autoexec.cfg so you enable the detail textures on every startup).

MS:C's focus is not graphics, as is clear in our maps and in sticking with the HL1 engine.

 

[Thothie]

One of the major goals of the original MSC team, when migrating from MS 1.35, was to update the graphics for more modern equipment. It would have been nice if more of these lag inducing features had been optional (friggen OpenGL requirement), but Bloom Mod, and anything else we put into the game certainly will be.

And if someone wants to do all that work for r_detailtextures, I'll put it into the betapack, don't ye be doubting.

 

[Glorfindel]

managed to update thornlands with just 3mb(raw) worth of textures

I will work on getting a detail texture for every texture in allinone, but discounting !(name) textures that's still about 5000 to do. It'll probably be around 300-500 detailtextures for the entire pack I estimate..

edit: so far I've done about 500 and only added 6 new textures, hmm

 

[jon50559]

Impossible odds ftw. I'll help if you want, just drop me a PM.

 

[Dridmar]

How do you do that?

 

[J-M v2.5.5]

If I knew how to make detail textures, I'd try to include them in my upcoming maps (that are very, very slowly nearing completeion).
PLZ EXPLAIN

Also; I know Wicard Oven is currently the only map with detail textures. Back when replica announced it, I wasn't really impressed, to be honest, but this thornlands animated GIF really shows a significant difference.

So to summarize:
A++, will watch neat animated GIF demonstrating the benefits of detail textures again.

 

[CrazyMonkeyDude]

I had one key bound to r_detailtextures 0 and the other to " 1, and when you spammed them it made my eyes hurt. It made me sad when we went to bloodrose after and the textures looked all blurry in comparison.

If I was any good with textures, I would lend a hand, but it seems some more modelwork (namely consolidation) is in my future as well...

 

[Glorfindel]

http://www.twhl.co.za/tutorial.php?id=159

Basically you make a .tga that's below or equal to 512x512 (that's the highest I've seen them and been able to get them) that's greyscale. This goes into the gfx/detail folder, and then a (mapname)_detail.txt in the /maps folder tells the game which texture to put on what. Like this:

{ranke detail/tl_ivy 3.0 3.0
{rebar01 detail/tl_metal 2.0 2.0
{reddrn detail/tl_metal 3.0 3.0
{rv_lampiron detail/tl_metal 2.0 2.0

Those are my four latest lines.

What I plan to do is designate a detailtexture for every texture in the allinone.wad that I have http://www.msremake.com/forums/viewtopic.php?f=37&t=8064&p=122290&hilit=allinone#p122290

So all a mapper will have to do (if they use the textures from that wad) is copy any map's detail.txt and rename it to *theirmapname*_detail.txt

Mappers can of course add in their own custom detailtextures for the allinone.wad or from their own custom wads simply by editing their _detail.txt file and putting their .tgas in the gfx/detail folder.

Impossible odds ftw. I'll help if you want, just drop me a PM.

Yeah, but it's too much work to really coordinate work efforts. Literally having someone start on the other end of the .wad and finding out when we meet halfway would be an ordeal in itself. I should be able to get it done within a few days, it's simple data entry. (Although the detail file will probably be in the hundred thousand characters by the time I'm finished...talk about a lot of typing...)

 

[Thothie]

The only times I've seen r_detailtextures in action have been disapointing. Wicard Oven, in particular, only seems to have a filmy grain over all its textures. But what you've managed to do in that thar Thornlands demo is above and beyond anything I've ever seen the function manage to pull off before! (with the possible exception of a certain Brain Bread reactor map, and bump mod, which uses an entirely different render method.)

Makes me wonder if the detail textures for Wicard Oven are setup wrong, or some such.

PS. In answer to your skybox question, we are restricted to the standard Half-Life 256x256 panels. Howevah, I do have the ESF source code which seems to allow for larger skyboxes in different formats. Howevah, again, we've got a ludicrous number of skyboxes already, and my record for porting code from other mods is kinda mixed.

 

[Glorfindel]

That grass texture up there now looks twice as crisp since I increased the size of that texture from 256x256 to 512x512. So it should look EVEN BETTER when I release the files. Up to 11mb now with 33 detailtextures.

I looked at the wicardoven ones, the reason they are all not impressive is because they

A) Lack contrast
B) Are all 128x128, which is about the same size as normal half-life textures are

However, it probably was a simple tradeoff for the mapper. That map has 41 detailtextures which amounts to 2.71mbs, which is great for space. Then again, a 10~mb difference probably isn't big enough to justify that much of a difference in potential detail these days.

 

[Thothie]

Not too worried about size... Intend the next patch to come in the form of a new full installer, in anycase. There'll be an upgrade patch as well, but even with all this added, it'll be tiny in comparison, as it won't include all the stuff from FEB2008-MAY2010, as it'll be strictly a MAY2010->JUL2010 (or AUG2010) patch.

 

[jon50559]

The only issues I have with this effect is over-usage. I had a friend who added detail-textures to one of his maps, but he went way overboard on it, EVERY texture and spot in the map had some kind of detail texture, and the effect was simply overwhelming.

Perhaps keep it do mostly floor/walls/ceilings/large details?

 

[Glorfindel]

The only issues I have with this effect is over-usage. I had a friend who added detail-textures to one of his maps, but he went way overboard on it, EVERY texture and spot in the map had some kind of detail texture, and the effect was simply overwhelming.

Perhaps keep it do mostly floor/walls/ceilings/large details?

I'm skipping all "one-time-use-only" textures and signboards, symbols, bookcases, objects, etc. The major players are wood, plantlife, forests, concrete, (there's actually tons of concrete textures! it was invented by the roman empire! but lost in the middle ages so...how does this make sense? MAGIC.) brick, dirt, grass, and general stone. What I'm finding is due to the stretching that most mappers did for wood textures, most of the detailtextures simply change the colour scheme for the primitive. Like edana, turning detailtextures on simply gives the town a palette swap on its wood beams, which actually makes it look much more together and nice.

A major problem I'm having is some detailtextures not being applied, and I believe it's because of what that tutorial up there warned about -- that is, mappers making the property of some brush different than normal. This most irks me about the beginning temple of urdual and gatecity's temple, I'm unable to add any detailtextures to their textures because of some property that the entire place has. I'm thinking it makes the place glow or something, I'm not sure. Either way, certain parts of maps will never have detailtextures unless they are recompiled with the properties of those brushes changed. My favorite map, keledrosruins, suffers heavily from this.

At least that's what I assume anyway. I've double(triple, quadruple!) checked my work, so, no typo or error on my end.

 

[jon50559]

Well babeh you better know there's one person (<----) who will be putting these to use!

 

[Thothie]

there's actually tons of concrete textures! it was invented by the roman empire! but lost in the middle ages so...how does this make sense?

Me thinketh someone stucketh the half-life.wad into the allinone.wad. Black Mesa involves a lot of concrete.

A major problem I'm having is some detailtextures not being applied, and I believe it's because of what that tutorial up there warned about -- that is, mappers making the property of some brush different than normal. This most irks me about the beginning temple of urdual and gatecity's temple, I'm unable to add any detailtextures to their textures because of some property that the entire place has. I'm thinking it makes the place glow or something, I'm not sure. Either way, certain parts of maps will never have detailtextures unless they are recompiled with the properties of those brushes changed. My favorite map, keledrosruins, suffers heavily from this.

Hrmm... Can't think what this might be. There are mirrors in the Edana's Temple of Urdual and (I think) Gatecity's, dunno if that might be a factor (might try setting ms_reflect 0, and see if anything happens). No such thing going on in Keledrosruins though (and a bit stickier there, if there were, as I think there be no source). I know that r_detailtextures don't work on glass though. Dunno if they have issues with func_walls and such, but surely not all brushes in those places are entity brushes (though the catwalks in keledrosruins all are).

 

[Glorfindel]

Nope, I'm completely wrong. I should've expected this. The detail file I was using for all my tests was a master copy with around 2000 entries, and I assume the engine cuts out parsing the lines at 256 or 512. It simply wasn't updating.

Which meansss I'll have to use a program to find out what textures each map uses, ctrl+f for each texture in my master copy, and then copy and paste those entries to their own separate detailtexture files. What a bother. At least some maps have their own wads so they're easy to find out what they use.

Is the tile in the temple too much?

 

[jon50559]

The tile in the temple looks superb, but the gound in the second edana picture looks too grainy for my tastes. I like what you did on the walls though, really makes the texture 'pop'! Try to do the same on the ground please

 

[Thothie]

Nope, I'm completely wrong. I should've expected this. The detail file I was using for all my tests was a master copy with around 2000 entries, and I assume the engine cuts out parsing the lines at 256 or 512. It simply wasn't updating.

Which meansss I'll have to use a program to find out what textures each map uses, ctrl+f for each texture in my master copy, and then copy and paste those entries to their own separate detailtexture files. What a bother. At least some maps have their own wads so they're easy to find out what they use.

BLARG!... Hrmm... Lemme see if I can help here...

You can use BSP Viewer to export all the textures in the map, including those in wads, to a single folder. File->Export->Bitmaps (Check both embedded and non-embedded check boxes). You can then go to that folder, drop a command prompt there, and use "dir *.bmp /o /b >list.txt" which will give you a text file in said folder called list.txt with all the textures. Just S&R the ".bmp" out and you should be good to go.

Alternatively, Quark can give you a text list of textures straight to the clipboard. Open map, right click on MipTex, click Properties, and click "Copy to Clipboard". Then you can paste the list into a text editor of your choosing... But for embedded textures it'll actually show the binary data, so, you'd have to filter that somehow, and thusly, BSP Viewer method likely much easier. >_>

Crafty tends to be made of fail for Half-Life1, but if you open the console (Help->Console), it'll list all the textures it could an couldn't find. You can S&R the "failed to find..." or "created texture..." entries, and go from there.

Seems there must be a better tool for this, but the BSP Viewer method isn't too bad, I suppose.


Glad you have the patients for something like this... I was just looking into the prospect of merging all the models in the misc/ and props/ folders, then editing all the maps to use the consolidated models (now that the body attribute on env_model is working). But alas, despair at the monumental task set in real fast. >_>

 

[FER]

Merging ALL models together? why not just merge props together, etc?

I could try the task of merging props, and while we are at it try to make more lamp models out of the brush based one, however JMs prefab misses some lamp brushes like from kfortress. Either that or I suck at using hammer

 

[Thothie]

Well, I was going to do them in simple categories... "Trees" "furniture" etc. But one bugger with it is that there's no way to preview the submodel in Hammer, which would make placement neigh impossible. (Could likely fix this, but the Hammer source code is a closely guarded seeekret for some reason or other). I guess, what you'd have to do, if you were working on a map, was place the models normally, then go back and replace them with the consolidated models, looking up the proper submodel index, later.

I tried making the first model a kind of "shadow" model with all the models in the set merged into one, so you could see where they'd go in Hammer, but it just made too much of a mess.

A few of the prop models have simple animations, which requires the wolf-rat-bear trick to merge properly. Some have odd origins, but I suppose that isn't an issue, provided said odd origin is retained to match up with the model it is going to replace. Sometimes differing textures have identical names, in which case you gotta rename and S&R the SMD.

I started with it, and made comments in the QC so I would be able to look up what model to replace, thusly:

$bodygroup props
{
//studio all_combined //shadow model for placement
//props/foliage1.mdl
studio arc_fern
//props/arc_fern.mdl
studio arc_fern2
//props/pi_fern.mdl
"studio" "FERN_reference"
//props/arc_bush.mdl
"studio" "arc_bush"
//props/pi_shrub.mdl
"studio" "pi_shrub_ref"
//props/pi_twig.mdl
"studio" "twig_ref"
//props/bush.mdl
"studio" "bush_ref"
//props/arc_flower.mdl
studio "arc_flower"
//props/grass1.mdl - funky origin (raise a bit)
studio "grass"
//props/grass2.mdl - funky origin (raise a bit)
studio "grass2"
//props/pi_tree1.mdl
"studio" "tree_grey_ref"
//props/pi_tree2.mdl - use anim seq #1
"studio" "tree_gshaded_ref"
//props/pi_tree.mdl
"studio" "pi_tree_ref"
//props/pi_treeb.mdl
"studio" "pi_treeb_ref"
//props/arc_xer_tree2.mdl (identical to arc_xer_tree1.mdl, so substitue)
studio tree1
//props/pine.mdl - three submodels, funky origin (lower slightly)
studio "lod2"
studio "lod1"
studio "ref"
//props/hessi_baum6.mdl - funky origin (raise a lot)
studio "b3"
//props/hessi_zypresse.mdl - funky origin (raise a lot)
studio zyp
//props/saint_grass.mdl - five submodels - use anim seq #2
studio ref01
studio ref02
studio ref03
studio ref04
studio ref05
}

Or, more to the point, here's the source for all the plant/tree models in /props combined:
http://www.thothie.com/msc_dev3/omg_plants.rar

Hrmmm... Maybe if I combined two or three submodels into that shadow model, instead of all the models into a giant cluster f*ck model, it might make for easier placement.

Meh, not really.

Ya know, looking at props/pine.mdl, I'm not even sure if you could really place that one, as it sits above its intended origin. So you'd have to place the model so it's origin was below the ground, if you wanted it to look right. It'd then vanish, lest the ground was a func_wall or something. :/ (edit: NVM, model's fine, just gets screwed up by the idle in my consolidated. I'll have to add another idle anim. :/)

 

[Thothie]

In other news that'll make your graphics card cry out, "WHY! OMG WHY!?"

Actually, MSC's new bloom feature seems to have no impact on my graphics card, but the code is using an nVidia optimized graphics library, so I dunno how it'll treat ATI's. (Nor OS's that can only emulate OpenGL, like Vista/7.)

 

[Crow]

MY EYES