On Color, Materials and Lighting

First I should say what everyone says - yeah it's been a while. One excuse is I always think it'll take me a long time to write anything here so I put it off. That's because I want to write well, so I spend a lot of time expanding explanations. Maybe I can put more stuff in this blog if I just write my fast way - which is usually point lists.

Reading 'OpenGL SuperBible' by Richard Wright has given me something to say. I'm at the chapter on Color, Materials and Lighting. I think specularity should be a property of the material, not a lighting property. Every surface should have a reflectance specification. Then the amount of normal light that bounces off surface would be calculated.

Thus one would specify 'dull', 'matte', 'bumpy', 'shiny', 'glass' for surface (numerically). This could be specified per-vertex, like colours, and get gradiented like colours are. Or reflectance surface could be like a texture, but each pixel is a reflectance value 0.0-1.0. This would just specify the proportion of light that is reflected - at incidental angle. Or each point of the reflectance surface could be a vector showing which way that point points, so the renderer could calculate where the light reflects to.

You wouldn't need a specular light, or even a diffuse light. The rendering engine could calculate the effects of light bouncing off a shiny surface onto other surfaces for diffuse light. It will take more CPU, but provide more realism.

Because really what you want is to say there's a huge sun millions of miles away, but only its rays provide the primary luminance, everything else is reflected.

Also you want to add diffusion property for volumes, to define what happens to light passing through gas or water or glass. This is internal reflectance.

By the way, I have updated the projects list on the Nimajin web site.

So, it took 10 minutes to get the lighting points up, then another 20 for the picture, introduction, advertising and editing (and another 10 to fix fonts and spacing!).

TimetablEd Now Does Orders And Consists

The Post T railroad simulator timetable editor is gaining new capabilities rapidly! The main panel has been reorganized to show movement orders. This was made possible by compacting the operating days into a new selector that shows the days by their initial letter, in the same way shown by the Stops chart.

The Stops chart can show you trains running on only the same days as the train you're working on, or trains running on any days you select. In the Stops chart you can change the track a train stops on by dragging its bar up and down, or you can change the stop times by dragging left or right. You can change these in the Stops list as well, and there you can also add new stops and delete them.

The train's movement orders are shown in text on the train panel, and can be changed in the Edit Movement Orders window. This windows shows all of the movement orders in the system on the left and the details of the selected order on the right. What's shown on the right depends on the type of order. Shown here is an uncouple order with the convenient graphical decouple point selector just like in the simulator.

I found it easy to get lost in the maze of movement orders, so I added the 'Find' buttons. When you click one of these the editor shows you the order that produced or consumes the item you're looking for, so you can easily follow the trails of the parts of your train.

The train consist editor has been added. You can edit templates that may be used to create many trains that are the same, or create custom consists for unique trains. At the top is shown the consist of the train. These are represented as a list of vehicles in the same way as the uncouple order, but here extra information is included. The bottom line of each vehicle shows the coupler type at each end so its easy to match couplers. In the centre are shown letters for Traction, Electric (or Steam) and Passenger. An L in the top right corners tells you that the vehicle is loaded. You build trains by selecting a vehicle from the vertical list and adding to the consist. For any vehicle selected in the consist or the vehicles list, the editor shows all of its characteristics.

So the editor is nearing completion! Still to do is the timetable printing. And yes, there will be an easy method of scheduling regular trains. My goal is to make the most convenient railway schedule editor. I will consider any suggestions.

TimetablEd

In co-operation with SignalSimulation.com / Signalsoft Rail Consultancy Ltd. / Richard Plokhaar, railroad consultant and railway simulation developer, I am developing a new railway schedule editor. The editor makes it easy to set up the trains that will run through the new Signalsoft Post T series of railroad simulators.

While playing the simulator you are the dispatcher who must control the signalling and switching to allow the trains to stop and pass through your area of responsibility on schedule - the challenge is you are using 1950's era technology for communications and control! The simulation platform accurately reproduces train physics and events that effect their travel over your rails. It is useful as a simulation for railroad enthusiasts or as a complete simulation platform for modeling and analyzing real-world railroad traffic.

The timetable editor features:

• Entry locations & times, exit location
• Station stop locations & times
• Arrival, departure & pass-through events
• Textual & graphical representation & editing for easy conflict resolution
• Special orders editing (train renumbering, direction switching, coupling & uncoupling of complete consists)
• Train consist editing: locomotive & car selection
  
• Special train & activity designation
• Timetable printing

There will be a series of simulators, modeling various real-world railway centers. A simulator demo is available now at www.signalsimulation.com/content/category/3/7/7/

More information about the Post T series is available at www.signalsimulation.com

The editor and the first full simulation are in final beta testing stage and will be available spring 2009

Who Gets the Money?

I'll post a question just for fun, because everyone loves politics!
My question is: The oil industry makes massive profits - is it better for that money to be controlled by the shareholders, or would it be better if consumer prices were reduced so there were no profits and the money was left in control of the consumers? Who should get the money: investors/shareholders or people who did not participate in the development of the resource, but only consume the product?
It's not like the money does not get spent. Investors do spend the money on other ventures. Maybe they build the Burj Dubai. When consumers spend most of it goes to the local community for food, shelter and services.
The question came from a twisted path. I've been a contributor to Greenpeace for 20 years and I get a quarterly magazine. This month they pleaded to control the Alberta oil sands projects that are using and polluting water and stripping the land and killing birds. I don't agree with them entirely. Oil is important and we have to balance the good with the bad.
My view on water (tailing ponds) is that it always evaporates and recycles. You cannot run out of water and it always cleans itself in the long run. So using water in any amount is not bad.
My view on the land (surface mining) is that nature will reclaim it. It was not clean in the first place - it was full of oil. What they return after extraction is dirt with less oil. I don't see a problem there. Over time nature will blow in sand and soil and it'll be the same as it was. So using land is OK (but only up to the point where the reduction of vegetation threatens the support all of the life on the planet).
Burning gas to provide heat for the extraction process raises the greenhouse gas emissions and I think that is bad.
Anyway the project is huge. Being a tech nerd, I wanted to see how huge it is, so I went to look at it on Google maps (I entered 'Fort McMurray Alberta' - just look for the huge grey patch north of there). You can see the tailing ponds, you can see the huge dump trucks.
I thought I could get better pictures in Wikipedia. I read the Wikipedia articles on oil sands and Athabasca oil sands to learn the history, technology and economics (I love Wikipedia!). The articles say that they are building more mines out there right now, so there will be construction work out there for at least ten years. So I'm thinking, if I really get broke, there is work out there.
While describing the economics, they go into how it costs like $25 to produce a barrel of oil, which they can sell for $60 to $100. I'm thinking: that's an outrageous profit! Is it moral? If they just dropped the selling price to $30, reducing their profit, a huge amount of money would be left for the consumers to spend on other stuff, which would provide jobs for people. As it is, the investors use the profits to capitalize other ventures, which provide jobs for people.
So which is better? That the consumer or the producer gets to control the money… Oh, I won't give an answer. It's a really big question.
I might have posted this because I just read 'Trinity' by Leon Uris, about the English exploitation of Ireland, or maybe not. Who knows how minds work?

Centres are Circular Things

If the receptive field centre covers a large area, it will provide a really big output when it's focused on a round object (that fits within the centre).

Centre / surrounds make their biggest output when the centre is stimulated, and the surround is inhibited, like on bright points of light in the dark, like stars at night. Colour versions ought to provide their biggest outputs on round things that contrast with their background, like berries or fruits. Or maybe larger round things like flowers or rocks. Or maybe almost round things like insects or fish. Or maybe distant almost round things like birds in the sky. Then, also, large receptive fields could trigger on partially round things, like rounded corners or fingertips.
So maybe there's not really a curve detector in a brain at all? Maybe curves are detected by partial outputs from the centres of large receptive fields. If it contrasted enough, a semicircle in the centre of a receptive field would cause a positive signal. If the brain knows, 'hey, that positive signal came from a big receptive field', then it could assume that a curved thing is in the field, with its size relative to the receptive field size.

Centres Can Be Corners

Centre/surround receptive fields can detect corners!


Look at the diagrams: corners and angles produce stronger outputs than edges, but weaker than centre dots. If the next layer evaluates its input from receptive fields carefully (i.e. looks for values between edges and dots), it can inform its superiors that a corner is in its field. If that next layer is also getting input from edge detectors, one of these inputs can strengthen its corner detection.

Of course these mid-range values can also indicate some other messy patterns, but that kind of stuff can be neutralized by expectation.

MonoSLAM Port

At the Robot Vision conference, I was impressed by the presentation 'Realtime visualization of monocular data for 3D reconstruction'. This identified interesting features in a scene and used SLAM technology to track and map them in real time. I thought this would be useful for my object and scene measurement system. Such a system requires identifying objects, comparing them to others and building a map of their relationships. SLAM is great for mapping spacial relationships.
I jumped into this and found that Andrew Davison has made his monocular camera SLAM software available as open-source. So now I am adapting this to my machine: 1. building using Windows and VS9, 2. creating camera input for DirectShow, 3. revising the UI for Windows forms using WTL.
The source includes Davison's MonoSLAMGlow application code, his SceneLib, which implements the SLAM algorithm and VW34, the Oxford Active Vision Lab libraries. My plan was to use OpenCV and DirectX as the input and output for my port, but SceneLib is so centred around OpenGL, that it's a lot less trouble to use that instead of DirectX.
The OpenCV demos would not work with my cameras (I have a cheapo USB webcam and a Canon DV Camcorder that connects by FireWire). I tried their suggested alternatives. Only videoInput worked for both my cameras, but I found it uses a lot of CPU, waaay more than DirectShow, so why not just use DirectShow, which works fine? So that's what I'm doing.
VW34 comes with project files for VS7.1, so it wasn't too much trouble getting those built in VS9. The compiler found a few problems that I must yet report back to Oxford. VW34 has a lot of parts. I only used VNL, VW and VWGL. Most of the other parts are Linux UI adapters. VWGL is an OpenGL adapter that on Windows requires GLUT for Windows.
ScenelLib was built on Linux so I made VS project files for it. While porting Scenelib I found something interesting. It appears as though in GCC you can instantiate an array with a size specified by a variable, like this: int Size = fn(X); char Array [Size]; Microsoft C++ won't allow that! I had to change to malloc(). There's something weird in GeomObjects/calibrationtable.h that causes an inexplicable list of errors, so I removed all references to it.
I built my own camera grabber using DirectShow. DirectShow samples are available in the Windows SDK. I made this grabber run in callback mode, store the bitmap and post a message to the application's main thread. This uses 13% of my Core 2 Duo 6400 (2.13 GHz).
So now I've built a WTL application, linked in the libraries and I'm working on getting the OpenGL visualizations working.