|
Written by Jay Taoko
|
|
Sunday, 26 April 2009 19:36 |
|
Ever since I released the Phong shader demo, it felt natural that I should do a program featuring other lighting model available in the computer graphics literature. You know the common models: Phong and Blinn. Yet there are other models that have interesting properties: Oren-Nayar, Cook-Torrance, Strauss, Ward and Ashikhmin-Shirley.
I had a lot of help coming from this page: D3DBook. The shaders I use to implement the lighting models are heavily inspired from the shaders available at this link.
Every lighting model as a set of unique parameters accessible from the corresponding tad view on the control panel. The last tab view named "All Shaders" allows you to visualize all the lighting model at the same time. If you check the option "Global Color" you can assign the same diffuse an specular color to all the lighting model while you are on the "All Shaders" tab view.
Lighting Shaders.
There is one light in the scene and its position is fixed. You may wanna the different mesh available in the control interface. In mt opinion, using the sphere mesh gives you a better idea of the lighting model properties.
Lighting model with a sphere mesh.
For the controls, use the left mouse to rotate the camera around the object and the right mouse the move the camera closer or away from the object.
The executable for the demo is available here. |
|
|
Written by Jay Taoko
|
|
Monday, 06 April 2009 00:00 |
|
What is the best format for color representation? In game development you often encounter colors in the following format:
- Floating point format representation where every component is in the range [0, 1.0].
- Integer with value in the range [0, 255]
- Hexadecimal with value in the range [0, 255]
That is not all. You also have the choice between RGB, HLS, HSV representations among others. All these representations of colors inputs all comes down to the same thing. Yet, it is very convenient when you can use color values in any format you like. Artists and programmers may have different views on this matter.
Color widgets in DevTool let you choose the format you prefer. You can work with colors in linear RGB, HSV or HLS format and also you can choose to represent color values in floating point, integer or hexadecimal.
Color Input Widget.
Going from one representation to another requires only a simple conversion that anyone can do. Yet, it is always best when that conversion is only one click away in the user interface. |
|
Written by Jay Taoko
|
|
Wednesday, 25 March 2009 00:00 |
|
There are many statistics you want to get from your programs. If you are doing 3D graphics you certainly want to know the frame rate of your program or how many polygons are on rendered on screen at one particular moment. To get your numbers out, you can always print them on screen but you might cover IT almost completely if you have a lot of stats to render.
DevTool has some features to let you send your stats over the network interface to DevTool's client interface. Let's say you have some frame rate data you want to display on the client interface. All you have to do is create a Stat object and write your data to it periodically. The client interface renders your stats inside the appropriate user interface element.
The frame rate of the program is displayed in DevTool's client interface.
The time graph pictured above refreshes itself every seconds. If it does not receive new stats in time, the curve representing the stat will slowly fall to 0. However you can always configure the graph refresh period to match to the period at which you provide statistics data.
Sending your numbers over the network is a good thing as the simple fact of displaying data on-screen constantly eat up part of your CPU and GPU time during every frame. The time graph feature present in DevTool's client interface save you the code you need in your programs to manage and display your stats. |
|
Written by Jay Taoko
|
|
Thursday, 19 March 2009 11:14 |
|
As you know, the samples from DirectX SDK use DXUT to display widget controls on top of the 3D viewport. Here are the problems I see with DXUT:
- DXUT is fine when you need only a few controls. If you need more, the viewport to your application can become cluttered very quickly.
- Unless you design a placement system above DXUT, you have to position every widget on screen manually. And adding new widgets later on can force you to rethink your widgets layout.
- In DXUT you have widgets such as comboBox, buttons, sliders and EditBox. But if you are a 3D programmer or a graphics designer you need color widgets, curves controls, histograms, filters, textures, shaders and much more. DXUT is very limited in that regard.
- DXUT is inappropriate. If you want to implement a color widget, you have to use 3 independent sliders to simulate the red, green and blue components. And unless you do something for it you have no visual feedback of the color you are choosing.
- No separation between the application and the control interface. You must always be close to the computer on which the program is running in order to control it. While in today multi-platform and networked environment, you should be able to control a program running on a machine located anywhere in your studio or beyond.
These problems are not specifics to DXUT. I have seen many custom implementations of on-screen widgets suffering from the same issues. And if you are using OpenGL, it doesn't even offer something close to DXUT to begin with.
With DevTool you can solve all the problems I have mentioned above. You don't need to organize your widgets on the screen since they are represented in DevTool's client interface. And every widget represented in a way that gives you the feedback you need to design your programs. Also, the tree structure of the client interface let you organize your widgets to reflects the structure of your programs.
Here is what a sample using DXUT looks like:
DirectX "Local Deformable PRT" sample with DXUT.
You can clearly see that the sliders used for the color components offer no visualization of the selected color and no numerical representation of their values. Now, here is the same sample modified to support DevTool and the accompanying client user interface:
DirectX "Local Deformable PRT" sample with DevTool integration.
DirectX "Local Deformable PRT" sample with DevTool integration.
Now to the demo. It has two executables:
- A DirectX sample program modified to integrate DevTool's server interface.
- DevTool's client interface executable used to control the sample program.
Lets go over DevTool client interface user elements.
DevTool user interface.
- 1. Connect to the program located at the IP address provided in (5) and listening to the port provided in (6). When you start theclient interface, it is configured to connect to a program running on your local IP and with port 2001. So (5) and (6) will be automatically filled with correct values.
- 2. Disconnect from the program.
- 3. Synchronize the widgets with the program. This also reload all the widgets.
- 4. Delete the widgets. You can reload them if you sync with the program.
- 5. Your program IP address. By default, it is set to your local IP.
- 6. Your program listening port. By default it is set to 2001 but you may change it in DevToolServer.xml which is located in the program sample directory.
- 7. A spinning wheel. When the wheel is spinning, the client is connected to the program.
This demo has been tested successfully on the following configurations. Please report any trouble you may encounter.
- XP + Geforce 5600 FX
- XP + Geforce 6600
- XP + Radeon X1300
- Vista 64 + Geforce 8800 GTX
- Vista 64 + Radeon HD 4670
Note about the color control in the interface: if you hold the CTRL key and click on one of the color component, the other components value will be set to the one you clicked. This is a fast way to set all the component to the same value.
Here is the Demo. You will need the latest version of DirectX End-User Runtime.
|
|
Written by Jay Taoko
|
|
Monday, 02 March 2009 00:00 |
|
Using DevTool platform, client interfaces connect to a server embedded with the program. Game consoles and PC computers all have reliable network interface so it is a simple thing to have a server in your program that can receive requests from clients. And the server is not limited to one client connection at a time. You can connect many clients concurrently and the server answers each client request. For practical reasons, the number of clients that can connect to a DevTool server is limited to 10. That number can be changed but it remains bounded by resource limitations on game consoles.
When multiple clients are connected to a program, the server answers to each client with the same priority. The server also informs clients if they are not up to date with the latest changes made to the program by another client. |
|
|
|
|
<< Start < Prev 1 2 3 Next > End >>
|
|
Page 1 of 3 |