Page 5 of 7

Posted: 2005-02-27, 00:52
by KillerKind
Carsten wrote:What do you mean by "shaders"? (This term has several meanings in the presence of a MatSys.)
Exactly as you say, small scripts. :)
Carsten wrote:I've stopped my work on CaWE (at least for now), in favour of preparing the upcoming release. I'll put the entire Ca3DE project under SubVersion version control on Monday morning, and then will do nothing but completing it for the release.
Glad to hear.


Also, here is how the HL2 height2normal.exe works, if anyone is interested.

Within the "sourcesdk\bin" directory of your HL2 SDK install is the program hieght2normal.exe.

Save your height map image, with "_height" added to the name, in the same directory as the .exe.

Create a text (.txt) file with the following code:

Code: Select all

"bumpscale" ".02"
"normal" "1"
"nocompress" "1"
The text file should have the same name as your height map image, only with "_normal" in place of the "_height" tag.

Image Name: myimage_height.tga
Text Name: myimage_normal.txt

Drag and drop the text file on the height2normal.exe file.

The new normal map image will be created.


Posted: 2005-02-27, 02:51
by Kai
Well there are two ways of creating a normal map, like the way Carmack described ..

First way is using an image like a photo, but as i said, this method is not the best, due to fact that an image only provides information about hight (but not really about angle) and also tends to blur out at the "high-edges".

There is no best solution but if i use a greyscale image, its a mix of converted photo an manual fixed elements.
I suggest NOT to use converted nmaps from 2d images , just convert them for testing or preview purpose, because it more efficient to use the greyscaled image.
A greyscaled image is much smaller than the 24 bit rgb nmap, the mat system offers to use the bumpmap (even in addition with real nmap) ;)

The second way is to use a high res geometry as a reference for the nmap. This will give very great results but requires a lot of work.

I prefer this way for both "surfacetypes": flat and model

Flat means that it will be used for a flat surface like a wall or other levelgeometry.
Model is more complicate, it is the surface of a complex mesh like a weapon or a playermodel .. this requires the most work, and a good modeling skill.
do you really think that it would be productive to create grass or gravel based geometry solely for the purpose of creating a normal map?
No but it also makes no real sense to create a nmap for a flat grass surface. Normalmaps are nice but not the absolut key for good gfx.
Not all surfaces are suited to have nmaps..

Grass for example should not be a flat surface but made of view-aligned small patches textured with a alpha mapped texture ;) (but the grasstexture could be used for the floor)

Nmaps also really benefits from reflections, so specular surfaces are more suited with nmaps (metal, wet materials ..)
Speculars can be created by a light or a reflection cubemap ( very often used in HL2 due to better performance reasons)
It would be nice if you would write a tutorial, or quick "how-to", on your techniques. Your images are fantastic. I know a lot of people who would benefit.
Thanks, but what techniqe ? you mean creating the nmaps ? I planned to write tutorials, so dont worry, but this will take some time. And the first version will be in german on my site ^^ But i will offer an english version

Here is a short description:
For flat surfaces:

I start creating a plane an project the diffuse texture or reference photo onto it.
Then i duplicate the plane and start to increase mesh details, adding all surface details and sharp angles ..
After finishing i could also add a bumpmap onto the highres for very small details like wrinkels or cracks...
At the end the high poly mesh is used as reference to calculate the nmap of the low poly plane.
Sometimes i tweak the map in photoshop (removing seams, adding other details)
Thats it

The other way is more complex but same principle. Creating a highresmesh and than building a lowpoly out of it, or the other way (lowpoly first and then highres).

But you can ask more if you need detailed infos

Posted: 2005-02-28, 10:15
by Carsten
CaWE will most likely be included, although it will probably not be good for productional work. It will more be a preview and testing release.
Alternatively, I might also release it as separate package to a limited auditorium (e.g. all todays forum members).

I've picked the 1st of April for the intended release date.
Oh, and one thing is for sure: Future releases will not take as long as this one! I intend to make releases at least in 2 to 3 month intervalls in the future.

Posted: 2005-02-28, 12:16
by scott
Carsten wrote: I might also release it as separate package to a limited auditorium (e.g. all todays forum members).
Sounds good to me :) , certainly it would help you for bug finding etc

Posted: 2005-02-28, 23:09
by Shadow
thats cool carsten.
oh man... released the day b4 i go on vacation. and to late for spring break too. oh well beggars cant be choosers

Posted: 2005-03-04, 00:01
by KillerKind
Started to skin my laptop model and thought Carsten might like this render. :)



Posted: 2005-03-04, 03:31
by Shadow
haha nice dude. would be killer with some screen glow coming off the screen...

Posted: 2005-03-04, 03:53
by KillerKind
Yeah, good call Shadow!


Posted: 2005-03-04, 09:47
by Carsten
Woahhh! Superb!

I really like that one. :)

Is the image URL constant? (And possibly as jpeg?) If so, I'd make a new News posting at :groupwave1:

Posted: 2005-03-04, 14:09
by KillerKind
Yes, the image is constant. Here is a link to png and jpg format. For some reason the jpg render is not as crisp as the png. :oops: I'll have to look into this more when I get off work tonight. ... top-02.png ... top-02.jpg


Posted: 2005-03-04, 21:41
by Carsten
Your png is pretty uncompressed - I got it down from about 900 kB to about 250 kB just with loss-less png compression.
I also made another jpeg from it, which is just 46 kB in size. The difference is visible, but only in direct comparision.
Will post it to the News section soon. :)

Posted: 2005-03-05, 00:06
by Shadow
sweet. very sweet. im gonna have to learn how to texture and render now

Posted: 2005-03-09, 06:37
by KillerKind
I'm not sure if you mentioned this or not, but I have a few questions regarding the new material system.

1) Will there be support for alpha channels?
2) If so, will this be defined in the shader file?
3) Will the scripts be accessible for modifications?

I am guessing that number three is a silly question.

Also, since this is the Preview thread, here is a render of something I started on tonight. Not sure how it will turn out, yet.


Posted: 2005-03-09, 10:29
by Carsten
KillerKind wrote:1) Will there be support for alpha channels?
Sure. Anything specific you have in mind?
2) If so, will this be defined in the shader file?
Sure. :)
3) Will the scripts be accessible for modifications?
Sure. :D
I am guessing that number three is a silly question.
Not at all. The release of the MatSys will also include documentation, but here is a short overview about some of the terms, as I feel they need clarifying according to your questions:

The MatSys is a collection of Renderers. Each renderer is a separate DLL and implements the MatSys for one specific platform and one specific API. Initially, there will be renderers for OpenGL 1.2 (now r_style 4, although the new Renderer will support dynamic lighting even in this mode(!)), one for OpenGL extended for NV2X GPUs (now r_style 6), one for OpenGL extended for NV3X GPUs (r_style 7), one for the ARB v1.0 program extentions (mostly for the ATI folks, but also covering NVidia GPUs, roughly corresponding to r_style 8 ).
In the future, there will be even more renderers, e.g. such that also support the SHL technique of my diploma thesis, for OpenGL 2.0, for all flavours of DirectX, and possibly for other APIs and platforms (e.g. I'd like to see software based MESA rendering etc.)

Materials are defined in Material Scripts (.cmat files) that are similar to the material scripts of Doom3, essentially defining what textures are used for a material and many other properties.
It is important to note that Materials are independent from the Renderers. Renderers of course eventually take Materials for rendering, but Materials themselves can exist on their own as separate entities/objects.

Now, each renderer contains a library of Shaders. When a Renderer first sees a Material, it first looks into its library of Shaders, and picks out the one that is best suitable for rendering this material. (In fact, two Shaders are picked for each Material: One for the ambient contribution (no light source involved), and one for the per-lightsource contribution of the Material).
Note that the Shaders are C++ classes that -for example- encapsulate vertex- and fragment-programs (or software rendering or anything else).

For rendering somthing, a Shader is provided with a Material and a Mesh, and these three components together are used to render the object.

This is a very high-level overview of the relationships of the components of the MatSys. Mappers and Artists normally don't require such insights, btw.

To get back to your question:
.cmat scripts will of course be modifyable by anyone.
I also plan to enable everyone who gets the MDK to make own Shaders, but am still thinking about a way how this can be made possible without being required to compile code.
It will also require a lot of documentation etc., so maybe this last feature will only be in the release after the next.
Also, since this is the Preview thread, here is a render of something I started on tonight.
Great! :)

Posted: 2005-03-09, 20:09
by KillerKind
Many thanks, Carsten. All very good news, and more info than expected. :)

As to the alpha channels, I have a few things in mind. I will post more details on this when I have time, at work (office computer) at the moment.

Thanks again for the detailed information.