Szico VII

It can read old shaders exactly as the base renderer does. Your .mtr will basically be an identical copy of your original .shader, WITH any rend2 specific stages (such as normalparralaxmap) added to make use of its features. That way users can swap between renderers at will with no compatibility issues.

Rend2 uses a specific normalmap shader line which doesnt exist in baseja or q3map2. This must be put into a .mtr file which will overwrite the info in the .shader file (should your renderer be set to rd-rend2) q3map2 "faked" bumpmaps/normalmaps arent all that great - theres a tutorial on how to use it properly in the tuts section. Remember, the bigger the brush the lower quality the lightmap as theyre always 128x128 pixels and so look much worse over bigger lightmap surfaces, so you're best using multiple small patches to get the best effects. Did you actually change to the rend2 renderer using "cl_renderer rd-rend2" (into the console?)

Really weird that...maybe it is a videocard issue then... :/

So, do the trees work properly for you when using this pk3? Ambient settings are fine for low values if you juust want to tone up veeery slightly, say 10-30 at most. Or you can use _minlight to prevent everything from being brightened and only brighten those which are completely dark. The envmap can be changed to reflect the other sides of the map (but they dont exist yet so.. ) One more point - the q3map_alphashadow is the shader paramater that allows the compiler to use the alpha channel of the leaf texture to cast shadows See here --> http://jkhub.org/tutorials/article/97-shadowing-effects-and-alpha-shadowing/

@@Xycaleth q3map_sunExt seems to be bugged ingame when using the default renderer. BaseJA, rend2 both render the sky normally when using this shader command, however in OpenJK default renderer it seems to not recognise the deviance stage of the shader and displays the sky as a texture not found. Ive also noticed when taking screenshots, it does not preserve the antialiasing.... and fraps completely bugs out textures/skies/bootland { qer_editorimage textures/skies/sky surfaceparm sky surfaceparm noimpact surfaceparm nomarks notc q3map_nolightmap skyParms textures/skies/yavin 512 - q3map_sunext 1 1 1 1000 155 50 0.5 8 }Error is "unrecognised command "0.5" in shader xxxxx Wonder if this is due to any changes you made to the vanilla renderer?

@@Boothand - I added _castshadows "1" to the misc_models and changed the grass brushes to a func_group with _lightmapscale 0.25, which gives you nicer shadows at the cost of compile time and lightmap space Well Ive packaged everything I have in a pk3. OpenJK rd-vanilla has a bug with the q3map_sunext at present so you'll have to either run in base JA or using rd-rend2, or remove the q3map2ext line when you test AFTER compiling and then put it back in when you need to compile lighting again. Ill be interested to see if it runs properly for you when using this pk3 http://s000.tinyupload.com/index.php?file_id=08011130653871898963

models/map_objects/bootland/trees/pinestem4 { qer_trans 1.0 surfaceparm nonsolid surfaceparm nonopaque surfaceparm trans cull twosided q3map_alphashadow { map models/map_objects/bootland/trees/pinestem4 alphafunc GE128 rgbGen vertex } { map models/map_objects/bootland/trees/pinestem5 blendfunc blend rgbGen vertex } { map $lightmap blendFunc filter depthFunc equal } }Heres a lightmapped one that seems to work as well.

Weird, I dont get any error messages... :| I guess nolightmap wouldnt hurt to get rid of them. I have no idea why then...

@@Boothand - It does not require a lightmapstage or a nolightmap in the shader. The "lightmapped" spawnflag will do everything for you. And I still dont see any of those issues.... Did you re-run the compile with the shader posted above and the lightmapped spawnflags? No sky or other shader issues...

@@Boothand Its the "onlyvertexlighting" command paired with the "lightmapped" spawnflag on the models. Just remove the vertexlighting command and keep the lightmapped spawnflags. I forgot I'd removed that models/map_objects/bootland/trees/pinestem4 { q3map_alphashadow qer_trans 1.0 surfaceparm nonsolid surfaceparm nonopaque surfaceparm trans cull twosided { map models/map_objects/bootland/trees/pinestem4 alphafunc GE128 rgbGen vertex } { map models/map_objects/bootland/trees/pinestem5 blendfunc blend rgbGen vertex } }I moved the thread as it is kind of a help thread at present

You don't notice it at all, and realistically, for the very edges you would probably expect to see partially through to the trees behind anyway. Heres my PS4 And PS5 alpha As for the lighting, it takes a few seconds for me because 1) I reduced your skybox size (shouldnt really be using an actual "box" really anyway) and 2) didnt use a skybox shader with surfacelight paramater. Dont use a sky box light with surfacelight, Use one with q3map_sunExt

@@Boothand No probs - heres some closer up shots to illustrate a slightly finer blend after decreasing the first stages alpha a bit more

models/map_objects/bootland/trees/pinestem4 { q3map_alphashadow surfaceparm nonsolid surfaceparm nonopaque surfaceparm trans cull twosided { map models/map_objects/bootland/trees/pinestem4 alphafunc GE128 rgbgen vertex } { map models/map_objects/bootland/trees/pinestem5 blendfunc blend rgbgen vertex } }I got around it by using 2 opacity stages. The first (GE128) gives you the blocking effect and transparency, and then the overlaying blendfunc gives you the smoothed edges. You'll need 2 separate alpha images, I made the pinestem5 alpha slightly larger and the pinestem4 (for the GE128) slightly smaller using darkness tool in photoshop. This IS 2 rendering passes though so for a lot of trees will take a performance hit, presumably. You can adjust the alpha at your own discrepancy NB: I also made it blocksize 0, removed the lightgrid worldspawn key added basic lighting. (And changed water for effect )

It doesnt for me... Perhaps you could send me whatever model + test map you are using to see If I can duplicate it

Well I couldnt get it to work with a full lightmap, but with onlyvertex lighting it works just as well textures/blueice_nightfall/nightfall_treebranch { qer_editorimage textures/blueice_nightfall/nightfall_treebranch qer_trans 1.0 q3map_onlyvertexlighting surfaceparm nonopaque surfaceparm trans surfaceparm nonsolid cull twosided { map textures/blueice_nightfall/nightfall_treebranch blendfunc blend rgbGen vertex } } #01 Vertex Lit with blendfunc blend #02 Lightmapped with alphafunc GE128

It just looks like the alpha channel isnt very good to me. No, actually, I dont think twosided is any different from none. Have you tried adding "depthWrite" to your main texture stage? You can have lightmapped gradual transparency, you just need the right lightmap stage as mentioned in last post using depthfunc equal - Ive recently used it for lightmapped alpha faded water in the Bioshock map. DOnt know about how it works with a alpha blend in the texture itself.... models/map_objects/bootland/trees/pinestem4 { cull disable surfaceparm noimpact surfaceparm nomarks surfaceparm nonsolid q3map_alphashadow { map models/map_objects/bootland/trees/pinestem4.tga alphafunc GE128 depthWrite } { map $lightmap rgbGen identity blendFunc filter depthfunc equal } }Or, perhaps for gradual...: models/map_objects/bootland/trees/pinestem4 { cull disable surfaceparm noimpact surfaceparm nomarks surfaceparm nonsolid q3map_alphashadow { map models/map_objects/bootland/trees/pinestem4.tga blendFunc blend depthWrite } { map $lightmap rgbGen identity blendFunc filter depthfunc equal } }

textures/blueice_nightfall/nightfall_treebranch { qer_editorimage textures/blueice_nightfall/nightfall_treebranch qer_trans 1.0 q3map_onlyvertexlighting surfaceparm nonopaque surfaceparm trans surfaceparm nonsolid cull twosided { map textures/blueice_nightfall/nightfall_treebranch alphaFunc GE128 depthWrite rgbGen vertex } }Thats the nightfall shader -> worked pretty well to be fair. It uses vertex lighting to save on compile time but still looks fine. For a tree branch, do you not want all or nothing transparency? Its not like some bits of twigs are partially transparent are they? For gradual transparency with lightmaps, particularly used for already partially transparent surfaces + additional alpha blending, the "depthfunc equal" seems to be the magic parameter, otherwise you get the lightmap showing up and ruining the gradual blend even if the texture itself has successfully faded away ) AFAIK, Alphafunc describes how to use the alpha channel by the renderer, and blendfunc describes how various texture layers are mixed with each other. Theres a lot of duplicate commands too, for example blendfunc GL_ONE GL_ONE is identical to blendfunc add, and blendfunc GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA I think is the same as blendfunc blend. EDIT: Heres the documentation in the shader manual: http://q3map2.everyonelookbusy.net/shader_manual/ch6.htm ALSO - Use cull twosided

For discrete transparency you should really be using the alphafunc GE128 (or LT 128) command. If for somereason you really need gradual transparency youll need a depthfunc equal in the lightmap stage. Oh, and dont forget to ad the "lightmapped" spawnflag to the model in radiant.,

I just clicked the right link here: http://jkhub.org/tutorials/article/112-richdiesals-mapping-university/

http://web.archive.org/web/20081228205726/http://www.richdiesal.map-craft.com/darthg/Shaders_365/lesson2/sh365lsn2.htm

Needz dglow. And any possibility of making cubemaps work? Proper reflections would be sooo good.

Ah its okay everyone makes errors - the reason it was dashed is because unfortunately, people don't tend to read entire topics and if people come across threads like these with wrong info in the future they wont bother to check post 4 and 8 or whatever to find the real answer. They'll either start new topics to ask again or add on the same answer about it being wrong like 3 weeks later. Incidental question - If I add a model2 key to a func_entity as opposed to targeting a misc_model at the entity, does that make any difference to entity count? I recently noticed I can add .ase models to entities using this targeting method, as ase's don't usually work as non-static model. Made me wonder if it was just baked into the entity rather than the map in that instance... (Unless thats an openJK change)

Where dat indoor fog coming from?