FL might support Bump Maps and other features
-
Actually even if you get it to activate, DX 8 had problems with it. It had a real bad habit of not using the surface normals, making it show right only part of the time. Video cards have progressed a long way so hopefully those issues have been cleared up.
The format to do a bump in DX 8 is
txtr 0 - gray scale bump
txtr1 - base material
txtr2 - cube environment mapThe shadow map stuff is used in the SP campaign. You can watch for a darker gray area under Trent and Juni in mission 1 while they are walking in the launch bay.
-
Unfortunately making it work everywhere would be just as complicated as porting to DX9, so I’d rather have DX9 right away
-
-
tomsons26, you are mixing things up: This “bumpmap” is a normalmap, but direct3d 8 only supports grayscale bumpmaps, which are more like heightmaps.
Either way, unless you can set a flag for a material so that fl uses the texture as bumpmap I doubt it can be achieved that easily.
-
Here is everything that is read as part of [RenderPipeline] in dacom.ini (except MGSDB). Parameters are for you to discover…
FPU_PRESERVE ZENABLE WRAP3 MULTITHREADED FILLMODE WRAP4 PUREDEVICE SHADEMODE WRAP5 SOFTWARE_VERTEXPROCESSING LINEPATTERN WRAP6 MIXED_VERTEXPROCESSING ZWRITEENABLE WRAP7 HARDWARE_VERTEXPROCESSING ALPHATESTENABLE CLIPPING LOCKABLE_BACKBUFFER LASTPIXEL LIGHTING USE_SYSLOCK SRCBLEND AMBIENT HANDLE_SWAPLOSS DESTBLEND FOGVERTEXMODE TEXTURE CULLMODE COLORVERTEX LIGHTING ZFUNC LOCALVIEWER TEXTURE_LOD ALPHAREF NORMALIZENORMALS TEXTURE_ALLOW_8BIT ALPHAFUNC DIFFUSEMATERIALSOURCE TEXTURE_ALLOW_32BIT DITHERENABLE SPECULARMATERIALSOURCE TEXTURE_ALLOW_DXT ALPHABLENDENABLE AMBIENTMATERIALSOURCE BROKEN_MULTITEXTURE FOGENABLE EMISSIVEMATERIALSOURCE VIEWSPACE_LIGHTS SPECULARENABLE VERTEXBLEND CLEAR_COLOR ZVISIBLE CLIPPLANEENABLE CLEAR_ZDEPTH FOGCOLOR SOFTWAREVERTEXPROCESSING CLEAR_STENCIL FOGTABLEMODE POINTSIZE STATE_CACHE FOGSTART POINTSIZE_MIN BROKEN_MOD2X FOGEND POINTSPRITEENABLE BROKEN_FLIP FOGDENSITY POINTSCALEENABLE DEVICE_GEOMETRY EDGEANTIALIAS POINTSCALE_A TEXTURE_SQUARE_ONLY ZBIAS POINTSCALE_B TEXTURE_MAX_WIDTH RANGEFOGENABLE POINTSCALE_C TEXTURE_MAX_HEIGHT STENCILENABLE MULTISAMPLEANTIALIAS TEXTURE_CUBEMAPS STENCILFAIL MULTISAMPLEMASK DEPTH_BIAS STENCILZFAIL PATCHEDGESTYLE FOG_VERTEX STENCILPASS PATCHSEGMENTS FOG_PIXEL STENCILFUNC DEBUGMONITORTOKEN FOG_RANGE STENCILREF POINTSIZE_MAX FOG_W STENCILMASK INDEXEDVERTEXBLENDENABLE RASTER_ANTIALIASEDGES STENCILWRITEMASK COLORWRITEENABLE DEVICE_SUPPORT_LEVEL TEXTUREFACTOR TWEENFACTOR TEXTURE_TRILINEAR WRAP0 BLENDOP DEVICE_BAD_MODE WRAP1 POSITIONORDER DEVICE_BAD_4444 WRAP2 NORMALORDER
-
NORMALIZENORMALS
NORMALORDERnormal maps?
and yes directx 8 and older dx’es support normal maps - source
http://developer.nvidia.com/attach/6681
The pdf was created in 2000.11.14 -
My initial bump mapping comment was in reference to w0dk4 somehow porting Freelancer over to DX9 as part of Freeworlds.
tomsons26 wrote:
NORMALIZENORMALS
NORMALORDERnormal maps?
and yes directx 8 and older dx’es support normal maps - source
http://developer.nvidia.com/attach/6681
The pdf was created in 2000.11.14Those two things deal with normals, which give a direction to which way a polygon faces. Those two don’t have anything to do with normal mapping.
-
Those two things deal with normals, which give a direction to which way a polygon faces.
This is only partially correct, since the direction a polygon faces is determined through the order of the vertices. Normals are used for lighting calculations and are given per vertex (i am not talking about normal maps here ^^).
-
Normal mapping is just a method of altering the direction of the normals across polygons, which in turn changes how light is cast on the surface and creates shadows/highlights that normally would not be there.
Unfortunately normal mapping and bump mapping require a far more advanced lighting system than what FL provides. You’re chasing after a ghost here guys. The only viable way I’ve seen is what w0dk4 is doing with his DX9 port.
Seriously, stop thinking you can just flip a switch that says “turn normal mapping on”. The devs might’ve been in a hurry, but they wouldn’t have left a perfectly functional piece of code unused.
-
If anyone wants to check the strings out i used this to get them
http://www.peid.info/
u will need the string view plugin http://www.peid.info/plugins/string-viewer-4peid-v0.02.zip -
Admittedly I’m dumb as hell when it comes to this sort of stuff, but I looked at localviewer in dacom.ini (specular highlights) a long time ago, it can be set true/false and is set as standard false, which I think is a much simpler form of reflective lighting that just takes into account a light source and a single side facing it for the effect. You “might” have to change a lot more than a setting if you wanted to make it work in the true state which from what I remember is a much more specific reflection which takes into account the viewing angle, multiple faces, angles and lightsources and such. The game might not even be set up for that sort of complexity for all I know so I didn’t pursue it. To be honest, I like to think it’s best that I listen to FF from now on, there’s is no magic switch (except for the one called Adoxa!)
-
The blue texture you showed was a normal map as was stated above. DX 8 does not support those except through shaders. Even DX9 does not support it in the fixed function pipeline (FFP).
The bump supported in DX 8.1 & 2 was buggy on alot of cards. On one of my cards (a dx 8 card) it worked perfectly all the time, on a newer card it work work about 30% of the time. I left the feature in my animation program but was unable to really use it due to the lack of proper support on dx 9 cards. I tested it again earlier this year on a dx 10 card, same thing as the dx 9 cards.
The main reason is the mesh format. Normal FL meshes do not contain the extra tangent info, the bi-normal can be create by a cross product of the normal and tangent. The bi-normal can also be provided in the mesh as well. But these are not part of the FVF. What this means is a shader is required since it does have support for those in the vertex declaration. You can get around that by assigning it to the extra texture uv maps but the critical code needed to render it isn’t in the FFP.
I ended up using per-pixel bump mapping in my game engine. I didn’t use the FFP though, I used a shader. The best bet is to wait until W0dk4 releases the DX 9 port and implement a shader for it.
Why I say that is for example, I can mix 1024 point lights, a base, detail, normal (bump), specular and glow maps any way I want, all on a per-PIXEL, not per-VERTEX basis.
So W0dk4, so if you release it, I will be one of the first to play with it
-
adoxa wrote:
Here is everything that is read as part of [RenderPipeline] in dacom.ini (except MGSDB). Parameters are for you to discover…FPU_PRESERVE MULTITHREADED PUREDEVICE SOFTWARE_VERTEXPROCESSING MIXED_VERTEXPROCESSING HARDWARE_VERTEXPROCESSING LOCKABLE_BACKBUFFER USE_SYSLOCK HANDLE_SWAPLOSS TEXTURE LIGHTING TEXTURE_LOD TEXTURE_ALLOW_8BIT TEXTURE_ALLOW_32BIT TEXTURE_ALLOW_DXT BROKEN_MULTITEXTURE VIEWSPACE_LIGHTS CLEAR_COLOR CLEAR_ZDEPTH CLEAR_STENCIL STATE_CACHE BROKEN_MOD2X BROKEN_FLIP DEVICE_GEOMETRY TEXTURE_SQUARE_ONLY TEXTURE_MAX_WIDTH TEXTURE_MAX_HEIGHT TEXTURE_CUBEMAPS DEPTH_BIAS FOG_VERTEX FOG_PIXEL FOG_RANGE FOG_W RASTER_ANTIALIASEDGES DEVICE_SUPPORT_LEVEL TEXTURE_TRILINEAR DEVICE_BAD_MODE DEVICE_BAD_4444 ZENABLE FILLMODE SHADEMODE LINEPATTERN ZWRITEENABLE ALPHATESTENABLE LASTPIXEL SRCBLEND DESTBLEND CULLMODE ZFUNC ALPHAREF ALPHAFUNC DITHERENABLE ALPHABLENDENABLE FOGENABLE SPECULARENABLE ZVISIBLE FOGCOLOR FOGTABLEMODE FOGSTART FOGEND FOGDENSITY EDGEANTIALIAS ZBIAS RANGEFOGENABLE STENCILENABLE STENCILFAIL STENCILZFAIL STENCILPASS STENCILFUNC STENCILREF STENCILMASK STENCILWRITEMASK TEXTUREFACTOR WRAP0 WRAP1 WRAP2 WRAP3 WRAP4 WRAP5 WRAP6 WRAP7 CLIPPING LIGHTING AMBIENT FOGVERTEXMODE COLORVERTEX LOCALVIEWER NORMALIZENORMALS DIFFUSEMATERIALSOURCE SPECULARMATERIALSOURCE AMBIENTMATERIALSOURCE EMISSIVEMATERIALSOURCE VERTEXBLEND CLIPPLANEENABLE SOFTWAREVERTEXPROCESSING POINTSIZE POINTSIZE_MIN POINTSPRITEENABLE POINTSCALEENABLE POINTSCALE_A POINTSCALE_B POINTSCALE_C MULTISAMPLEANTIALIAS MULTISAMPLEMASK PATCHEDGESTYLE PATCHSEGMENTS DEBUGMONITORTOKEN POINTSIZE_MAX INDEXEDVERTEXBLENDENABLE COLORWRITEENABLE TWEENFACTOR BLENDOP POSITIONORDER NORMALORDER
Looking at most of what’s in this list and then checking up on microsoft and directx, it seems it might be mostly related to graphics drivers and hardware and a case of whether either can actually support the particular d3drenderstates or not. Maybe it ties into the flconfigdatabase.ini and allows for disabling of many of these features when the driver or hardware are unsupported.
These below are in the list you put up and exist in the dacom.ini for all to play with already.
[RenderPipeline]
MGSDB= FLConfigDatabase.txt;DEVICE_GAMMA = false ; forces gamma control off
;TEXTURE_ALLOW_DXT = false ; forces dxtn support offALPHAREF = 0 ; d3drenderstate: default alpha ref
ALPHATESTENABLE = true ; d3drenderstate: basic alpha test
ALPHAFUNC = 5 ; d3drenderstate: D3DCMP_GREATER
LOCALVIEWER = false ; d3drenderstate: specular highlights
zfunc = 4 ; default z compare func is D3DCMP_LESSEQUAL;FPU_PRESERVE = false ; should Direct3D save and restore the FPU state every time it needs to modify the FPU state.
;MULTITHREADED = false ; request multithread-safe behavior. This causes Direct3D to take the global critical section more frequently.; vertex processing flags are mutually exclusive
; regardless of what the user asks for if the device cant support hw-tl the user gets sw-tl
HARDWARE_VERTEXPROCESSING= true
;MIXED_VERTEXPROCESSING= true
;SOFTWARE_VERTEXPROCESSING= true;LOCAKABLE_BACKBUFFER= false ; should the device allow the backbuffer to be locked
USE_SYSLOCK= false ; should resources (vb, ib, texture) take a windows wide critical lock when in use
HANDLE_SWAPLOSS= false ; should rp attempt to handle device loss internally? ; a poor substitue for app-side management but makes tool building easier
;VIEWSPACE_LIGHTS = false;TEXTURE_CUBEMAPS = false
Adding entries for the antialiasing states to the list and true/falsing them has no effect….
Would be highly interested in knowing if there are any offsets for the antialiasing, i.e if it can set to 2x,4x,8x,16x or whether they are simply capable or not scenarios for the driver and graphics card. Somehow I have a feeling it would be the latter.