got working doors and little explosives (boxes to be shoot)
and usual barb-wire hurting fence inside blender.
Trying to make the differences between part of structure
or only detail brushes (is it only the value after the texture-scaling?).
Wanna have some climbable stuff (like ladders, envy…) too
and after cleanup, a small blender-2.61 map blendfile with
its export script will be posted soon.
Last, this is to thank king arthurs wizard for the help to get the gtkradiant
running on my box … – its easy to view the settings there and not such
a kind of miracle to see it there.
– new 18.may. – (but i stilll use blender-2.61)
little change in the export_map script,
a try to set things as “detail” and not “structural”
(but i am not total shure if its this brush-flag value)
depending of the layer-setting. All structural things
should be in the same layer as the worldspawn.
this sample is with:
moving doors, rotating, sliding, one-time-move, pending
flagpole to mark occupy
health/ammo-supply
hurt-things like the barb-wire
ladder to climb up the house
smoke, with smoke-direction
one speaker at white smoke for some fire-burn-sound
destroyable little boxes, to shoot up or blast with nade
still not working, the command-map-markers. There is
something wrong for the compile of the map (with etxmap)
because if the cm-markers are working (they only give
a on-screen-message like "you are near health-supply2),
then the ladder-brush loses its texture and cannot be
used to climb up - and the doors lose their origin to rotate.
no adjustment of textures and last to activate the rain, i still
have no clue - don`t know.
so there is no video or picture because the effect of those changes
are only for the kind of action and not for any graphics.
another little step, creation of larger terrain like landscape out of blender.
some pics:
The sample blend-file has it not made to the svn-site of otc6.
I have only the calculation uv-unwrap of rectangular faces in x or y-axis
orientation. The terrain is made of triangle-shapes and uses a displacement-map.
The buildings are only set into it and it looks a bit like in a desert with a lot of sand.
I still have the problem with objects crashing the map-compiler(etxmap, q4map) after rotation in blender (looks like the setting of the faces to grid-size gets lost - out of sync - with a rotation and i try to run a re-position of those vertices not on the needed quake-map-resolutions).
Needless to say, models are made with blender. Even some textures like the bump-map of the player-skull-heads. I tried to do simple textures for global mapped objects too and got nearly the same looking (besides light), so a texture in an material set to global, flat is exported as a baked-texture-image (a baked-normal-map too, like for the sand-texture).
maybe someone has a hint/solution why i cant get a clean baking
of the used textures.
this are 2 pictures -
one from the game-view
and one out of blender-2.61 with the map
from the distance the little break in the textures is not visible.
I use a separate scene in this blend-file to bake all materials to a flat plane,
but the plane has a funny size.
Its a square plane from left corner (0, 0) to diagonal corner (5.02, 5.02).
Even a little less, like only 5.01 will be show up in the stripes-texture as an offset at an fixed distance (where the texture is repeated).
This is the little script to generate all texture-mapping and normal-mappings for all materials (with “bl_” as first name-part):
import bpy
#
# ugly ... without knowledge ... baking to 1024x1024 png
# needs a plane 0,0 -> 5.02,5.02 -- why?
#
N_Scale = 2. #Normal-Map scaling factor ..
if True:
print(bpy.context.scene.name)
if bpy.context.scene.name != "BakeScene":
print("invalid scene selected")
else:
print("try . .. baking materials..")
rplane = bpy.data.objects["renderplane"]
bpy.context.scene.objects.active = rplane
print(bpy.context.active_object.name)
fshader = open("pak/scripts/bl.shader", "w")
for m in bpy.data.materials:
matchstr = "bl_" #"bl_brown"
if matchstr == m.name[: len(matchstr)]:
fpath = "pak/textures/bl/"
if len(rplane.material_slots)==0: break
rplane.material_slots[0].material = m
print(rplane.material_slots[0].name)
for t in m.texture_slots:
if t:
print("-----", t.name)
if t.use_map_normal:
t.normal_factor *= N_Scale #maybe change strength of normal-mapping?
for baketype, nameext in zip([ "NORMALS", "TEXTURE"],["_normal.png", ".png"]):
bpy.context.scene.render.bake_type = baketype
bpy.ops.object.bake_image()
bpy.data.images["bake_image"].save_render(filepath=fpath+m.name+nameext)
for t in m.texture_slots:
if t:
if t.use_map_normal:
t.normal_factor /= N_Scale #set scaling for normal back
fshader.write("textures/bl/"+m.name)
fshader.write("
{")
fshader.write("
diffuseMap textures/bl/"+m.name)
fshader.write("
bumpMap textures/bl/"+m.name+"_normal")
fshader.write("
}
")
fshader.close()
from the scaling (=100) of the output, i thought for a 1024x1024 image the bake has to go to a plane-size of 10x10, but that is wrong (from inside the game-view).
At this point i decided to stop with this way of mapping - old-school radiant-mappers will laugh about it anyway - because even now with the creation of a deluxe-map for this new map, the visible normal/bump-mapping is not what i did expect. (thats why there is this factor in the code above to increase the normal-map-value for the baking, because i thought the scaling of the output-map would need a higher normal-setting too).
(sorry did notice too late the huge size of the png-image … )
little script for blender-2.61
to create a labyrinth with walls suited for quake/et-map (q3map, etxmap).
image out of blender - with render in blender (after labyrinth creation)
and from inside etxreal-otc6-mod (after some time, most of the 60 players
are running thru the maze)
and the blend-file (for blender-2.61) with the script to ready to run
for the maze-generation and the few hundert lamps.
To use it as a map, after maze-creation the wall-mesh has still no texture.
The two blender-materials named bl_floor and bl_bricks are valid shaders
in the game-engine.
The picture from the game was made with a quick-compile of the map, only
the bsp-stage and the light-stages with fast-option and no extensive bounces.
Normaly no one would make such a map … cause its too huge - like the screenshot shows it is possible to look over the whole map.
tried some first tests with more normal-mapping and parallax-mapping,
but the performance-penalty is more than i thought. Two nearly
identical screenshots, both with normal-mapping on floor and building
and the second one with additional parallax-mapping.
I am using older hardware with an nvidia-8400-graka and the scene
without normal-mapping and quickest-shadows runs with 100fps.
(without shadows and 60 players it runs easy over 120fps)
just switch between both images to notice the different usage of parallax-mapping.
and here are some other with terrain-like map (terrain was made in blender)
the textures on the buildings would need to be adjusted in gtk-radiant, it was only to test the parallax-mapping for those plain faces.
