Generating Normal Maps

Normal maps can turn boring smooth shaded models into detailed and realistic looking ones. Generating normal maps are as easy. You just need a normal map generator( or write on yourself). here is tools:

NDO

This is a powerful photoshop plugin for creating normal maps. This was free then became a commercial project. The free one can be found here, but i think the commercial project was taken down. The author’s website is here and a tutorial is here.

NormalMapper

This application find the dfference between hi-res and low-res models and output the difference in normal maps. Link here.

NormalMapper(AMD)

AMD seems to have a normal map generator with the same name. It’s not in development anymore, but its still available for download.
link

SSBump Generator

This is a free tool for making self shadowed bump maps for valve’s source game engine
link

Normal Map Generator

Another free tool for making normal maps. Made by the same person who made the SSBump Generator. This one makes it easier to batch normal map coversions
download page

ShaderMap

This is a commercial software. It makes professional looking nomal, displacement, specular and ambient occlusion maps. You can visualize your normal maps on models in it as well. It also comes with an SDK for some reason :/. You can download the demo for free.
download page

xNormal

another software for baking normals from hi-res models to low-res ones in to normal maps
link
download page

MindTex

Commercial, but you can try it free for thirty days
link

CrazyBump

This is a popular one, and my personal favorite . It’s commercial, but comes with a 30 day trial but for its beta version. It generates normal, displacement, specular and AO maps like ShaderMap.

Gimp Normal Map Plugin

This one has free written all over it. You can generate normal maps right after drawing them and preview them on models. link

Resource:  http://nickthecoder.wordpress.com/2012/08/23/generating-normal-maps/

Useful IntelliJ Resources for dummies

Links on the IntelliJ site:

1. 1. The main documentation page
2. 2. Demos and tutorials including a couple of new Groovy support demonstrations
3. 3. 25 things you can do with IntelliJ 8 you can’t do with 7
4. 4. Mac Keymap reference
5. 5. Windows/Linux keymap reference
6. 6. The Jetbrains IntelliJ blog. A great way of getting tips from the guys that wrote it, and keeping up to date with improvements.

DZone: Intellij in 7 pages

1. 7. The DZone refcard for Intellij

My personal faves

1. 8. Command Shift-A to bring up a search window for actions. This one I think of as Quicksilver for my IDE.
2. 9. Alt-Enter to trigger intentions. Problem with your code? Let the IDE suggest a refactor to correct it.
3. 10. Ctrl-n for auto-generation of Java code. Getter and setter boilerplate getting you down(and you can’t switch from Java to Groovy)? Want a nice compact toString() on a class with 20 member variables? Let the IDE do the heavy lifting.
4. 11. The Javadoc Sync plugin. This goes well with #10 to javadoc all those getters and setters auto-magically.

Add logging using the debugger

1. 12. Printing to the console is a basic tool for debugging code. Everybody’s done it – because it’s easy and it works. But you often come across scenarios that disallow this quick and satisfying hackish behaviour. Namely when you are debugging into code in a library, this is not necessarily an easy option. Fortunately IntelliJ provides a nice easy way to add console logging through the debugger. You can access the breakpoint configuration dialog either by right clicking on an existing line breakpoint and selecting ‘Properties’ or by pressing Command Shift-F8 from the Debug view. From there you configure your line or Exception breakpoint with a ‘Suspend policy’ of ‘None’ and check the boxes under ‘Actions’ to enable logging. A full description of the features can be found here. I find this especially handy when there’s a problem iterating over a Collection and only one or some of the items in that Collection lead to an error condition during processing. Using this strategy I can provide context as to which cases passed and which failed without having to stop at a bunch of breakpoints and inspect the variables on the stack; I can just concentrate on the failure point and look back at the console output to compare against previous invocations.
   Here’s a couple of screencaps to show configuration for logging the size of a list on a line breakpoint. Note that the Groovy requires a little bit of extra magic, since the debugger gets passed a Reference object instead of the raw List.
   
   Resource: http://www.kellyrob99.com/blog/2009/08/18/my-favorite-intellij-resources-tips-and-tricks/
   
   http://www.jetbrains.com/idea/docs/IntelliJIDEA8_ReferenceCard.pdf