Gamestudio Links
Zorro Links
Newest Posts
Newbie Questions
by fairtrader. 12/05/23 14:22
Zorro Trader GPT
by TipmyPip. 12/04/23 11:34
Square root rule
by Smallz. 12/02/23 09:15
RTest not found error
by TipmyPip. 12/01/23 21:43
neural function for Python to [Train]
by TipmyPip. 12/01/23 14:47
Xor Memory Problem.
by TipmyPip. 11/28/23 14:23
Training with command line parameters
by TipmyPip. 11/26/23 08:42
Combine USD & BTC Pairs In Asset Loop
by TipmyPip. 11/26/23 08:30
AUM Magazine
Latest Screens
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Tactics of World War I
Who's Online Now
0 registered members (), 631 guests, and 2 spiders.
Key: Admin, Global Mod, Mod
Newest Members
fairtrader, hus, Vurtis, Harry5, KelvinC
19019 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
bumpmapping with commercial possible?? #54096
09/03/05 21:56
09/03/05 21:56
Joined: Nov 2003
Posts: 433
The Netherlands
T
Toon Offline OP
Senior Member
Toon  Offline OP
Senior Member
T

Joined: Nov 2003
Posts: 433
The Netherlands
Hello, is it possible to add some d3 bumpmapping to a few textures (with use of d3d_automaterial) i have the commercial editon.

Re: bumpmapping with commercial possible?? [Re: Toon] #54097
09/03/05 22:04
09/03/05 22:04
Joined: Jul 2003
Posts: 893
Melbourne, Australia
Matt_Coles Offline

User
Matt_Coles  Offline

User

Joined: Jul 2003
Posts: 893
Melbourne, Australia
Yes it is possible, there are many examples of this in the shader forum. try the shader collection too.

Re: bumpmapping with commercial possible?? [Re: Matt_Coles] #54098
09/05/05 08:43
09/05/05 08:43
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
Machinery_Frank Offline
Senior Expert
Machinery_Frank  Offline
Senior Expert

Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
.. or use the tool SMEE2.0 (general tools forum). There you can create your own bump mapping shaders.


Models, Textures and Games from Dexsoft
Re: bumpmapping with commercial possible?? [Re: Machinery_Frank] #54099
09/08/05 17:19
09/08/05 17:19
Joined: Oct 2003
Posts: 49
D
dirkmittler Offline
Newbie
dirkmittler  Offline
Newbie
D

Joined: Oct 2003
Posts: 49
Even though I'm not an expert, I think I should explain the concept of bumpmapping with 3DGS to you, so that you will also be able to *understand* the examples in this forum.

You esentially have a choice between two kinds of bumpmapping: DOT and Environment. A simple bumpmapping shader just modulates the prightness, or if you prefer a fixed specular colour, in response to the slope or derivative of the 'normal height' . And environment mapping is more limited with 3DGS, in that a simple shader won't reflect the real-time environment around an Entity. Instead, you really need to define an "environment cube" which will always seem to surround your entity in advance, so that your shader can reflect this environment cube. There is a documented function in the manual which converts *your* image into an environment cube, so that your shader will be able to address it correctly. But then your bumpmap will modulate the CameraSpaceReflectionVector .

The general concept of bumpmapping, is that your texture has a bump channel, in addition to RGB and sometimes A , so that small features don't need to be modelled. But with 3DGS, you haven't been provided a bump channel which your shader would need to load from the texture. So you must improvise here, and with 3DGS you have a lot of chances to improvise. One popular method, is just to use your Blue colour channel as your Bump channel. But your shader can derive a bump channel in other ways if you like, to map this 'normal height' . And normally, the math in your shader then does the work of producing this effect. Even though C-Script also features a function which finds the derviatives of your textures' Blue colour channel in direction u and direction v, thus transforming the texture (image).

In 3DGS the coordinates within a texture image are labelled u and v. Your script can even change the corresponding Skills of some enities over TIME, causing the texture to move in he desired direction.

Within the shader, X Y and Z coordintes are followed by a logical (1.0) to make a 4-component vetcor, so that multiplying this vector with a 4x4 matrix will perform any linear transformation of those coords. Thus, if you knew the equation

Y = MX + A

from Linear Algebra to convert 3-component vector X into vector Y, consider adding constant vector A as the 4th column of M, so that A will get multiplied by this quaternion and still get added to 4-component Y. The immense advantage of this is that it reduces the math of transforming coordinates from a multiplication and an addition to just a (matrix) multiplication. For this reason, a whole series of tranformations can be represented as a single matrix, and available ones are named matWorld, matWorldView, matWorldViewProj andsoon to get an object's X, Y and Z into the gameworld coords, then into coords around the camera, and then into screen positions as projections of the space around the camera. The game engine upates these matrices for you. And because 4x4 matrix multiplication in floating-point numbers is a single built-in operation of your graphics card's VPU, you can produce screen coordinates with only very few DirectX assembler ops.

But because doing this is still complicated, there are software tools recommended here, which will do the shader-programming for you. Another one which the other two didn't mention above was the Sphere plug-in. After all, even a minor mistake in the procedural shader will cause an image which looks grossly wrong. And with a *pixel* shader, you're responsible for writing the final colour directly to the pixel on the screen. Thus, you must then produce *all* the effects, because *your* pipeline circumvents even the post-processing normally built in to the game engine. You might find that shadows aren't cast onto your shader, unless you did something about that...

The *vertex* shader just defines the address on your texture image, from where the colour later gets read, thus modifying this address. This logically happens before the pixel shader gets called, and might still allow for engine post-processing if you didn't define your own pixel shader. Somebody please correct me if I'm wrong. Thus the programmed vertex shader ends in two assembly-language operations: oPOS outputs TO which POSition on the screen, and oT0 outputs FROM where within loaded Texture number 0. If you were working with more than one loaded texture (source) image, there would conceivably be an oT1 instruction for the second one...

In HLSL you refer to numbered loaded textures with square brackets.

Dirk

P.S. If you absolutely need to have an indepndent Bump channel: A 3DGS Model Entity is allowed to have up to 4 Skins and not just one. Your first Skin could contain only colour information, but Skin2 could be loaded as your second Material Texture. Then, the Blue channel of Skin2 could become your Bump channel if you programmed accordingly. You could use your own 2D graphics software to paint your second Skin to match your first.


Last edited by dirkmittler; 09/08/05 19:27.
Re: bumpmapping --> d3d_automaterial. [Re: Toon] #54100
09/10/05 18:07
09/10/05 18:07
Joined: Oct 2003
Posts: 49
D
dirkmittler Offline
Newbie
dirkmittler  Offline
Newbie
D

Joined: Oct 2003
Posts: 49
I have given more thought on your behalf, of what you could do to bumpmap your entities using a completely independent bumpmap from the Texture's or Skin's colour components. And my earlier suggestion still seems plausible to me, that you could give your Entity 2 Skins, and that the Blue component of its second Skin could act as your normal heightmap. But I was surprised to find out just yesterday, that you can't really access the Entity's Skin2 directly. And so your material would need the following property. You would need to give it an event function that does something like this:

function myent_bump_assign() {
mtl.skin2 = bmap_to_uv(bmap_for_entity(me, 2));

(...)

}

material myent_mdl {

(...)

event = myent_bump_assign;
}

If you used this strategy, you might not even need to use d3d_automaterial, since the event will find the bumpmap for each entity, every time the same material is assigned to one. But I'm not 100% sure that to assign a pointer directly to mtl.Skin2 will work. You should try. And it could become a mess to paint a separate bumpmap Skin for the entities. With Adobe PhotoShop you would do this by making a second layer over your image, setting its mode to "additive" and then saving that layer as a separate image after you're done.

Dirk


Moderated by  Blink, Hummel, Superku 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1