Josh

I am usually very excited to read about new graphical techniques, and even new hardware approaches, even if they are presently impractical for real use. I was very interested in Intel's Larabee project, even though I didn't expect to see usable results for years. However, sometimes articles get published which are nothing but snake oil to raise stock prices. The uninformed reader doesn't know the difference, and these articles are usually written in such a way that they sound authoritative and knowledgeable. It's unfair to consumers, it's unfair to stockholders, and it hurts the industry, because customers become unable to differentiate between legitimate claims and marketing nonsense. This one is so over-the-top, I have to say something. In an attempt to stay relevant in real-time graphics, Intel, the company that single-handedly destroyed the PC gaming market with their integrated graphics chips, is touting anti-aliasing on the CPU. There's a nice explanation with diagrams that make this sound like an exciting new technique Intel engineers came up with. The algorithm looks for edges and attempts to smooth them out: It's so advanced, that I wrote this exact same algorithm back in 2007, just for fun. Below are my images from it. Original: Processed: The reason this is dishonest is because you would never do this in real-time on the CPU. It may be possible, but you can always perform antialiasing on the GPU an order of magnitude faster, whether the device is a PC, a netbook, or a cell phone. I don't think Sebastian Anthony has any clue what he is writing about, nor should he be expected to, since he isn't a graphics programmer. Furthermore, swapping images between the GPU and the CPU requires the CPU to wait for the GPU to "catch up" to the current instructions. You can see they completely gloss over this important aspect of the graphics pipeline: Normally, graphics are a one-way street from the CPU, to the GPU, to the monitor. The CPU throws instructions at the GPU and says "get this done ASAP". The GPU renders as fast as it can, but there is a few milliseconds delay between when the CPU says to do something, and when the GPU actually does it. Sending data back to the CPU forces the CPU to wait and sync with what the GPU is doing, causing a delay significant enough that you NEVER do this in a real-time renderer. This is why occlusion queries have a short delay when used to hide occluded objects; the CPU doesn't get the results of the query until a few frames later. If I made the CPU wait to get the results before proceeding, the savings you would gain by hiding occluded geometry would be completely negligible compared to the enormous slowdown you would experience! What Intel is suggesting would be like if you went to the post office to mail a letter, and you weren't allowed to leave the building until the person you were sending it to received your letter and wrote back. They're making these claims with full knowledge of how ridiculous they are, and counting on the public's ignorance to let it slide by unchallenged. So no, Sebastian, this is not going to "take a little wind out of AMD’s heterogeneous computing sails". Please check with me first next time before you reprint Intel's claims on anything related to graphics. If any Intel executives would like to discuss this with me over lunch (your treat) so that I can explain to you how to turn the graphics division of your company around, I live near your main headquarters.

I have a press release going out Monday night for the release of LE 2.5. I need to get these things in order before then, or postpone the release a week. We are switching from Project Wizard to LE Builder, but there are some problems: 1. The SDK path selection step should be removed. The SDK path should be the same directory as wherever LEBuilder is located. 2. The VB.NET and C# templates should be included in LEBuilder without having to import a new template. 3. I don't understand where the C# header files should go in the SDK directory. Version 2.5 is up right now. You can download it and see how things are laid out, and tell me what needs to change. Thanks for your help.

Yes, and it would happen all the time, in scenes that don't use either.

I'm not sure if calling those commands will impact performance or not, but that is kind of odd. The performance of Leadwerks Engine is not usually impacted by the amount of geometry onscreen. The performance tends to be limited by the screen resolution, effects settings, and the number of shader pipelines the GPU has.

I use this in Xcode and VS all the time, and it's a great feature. I don't know if it will make it into the first release, but I agree it's very useful.

The saved files are located in "C:\Program Files\3D World Studio\maps" by default.

Ah, matrix math. That matrix looks right. Line 1: The local x axis points at 1,0,0 Line 2: The local y axis points at roughly 0,0,1 Line 3: The local z axis points at roughly 0,-1,0 So the object is pointing down, which makes sense with a euler rotation of 90,-180,180. That's where gimbal lock sets in, so the yaw and roll are a little funny. The scale should be 1,1,1 and it's only because of floating point imprecision that it's not. That happens all the time and isn't a problem.

It's the old ease-of-use vs. quality of results conflict. I think you guys will be happy with how I worked it out. I am coming from a programmer's point of view, but realize the market probably values a visual art pipeline above anything else.

Really, I'd like to play a 3D game on the iPhone that doesn't suck. Something like Mario64 would be really fun. If there was a game like that available I would buy it.

You have to have the texture somewhere in the Leadwerks Engine SDK directory. You can change the path the tools use to load assets from in their settings file. LE3 uses a more drag and drop approach.

That seems counterintuitive, because assets are reusable and scenes are unique.

It took a while to figure out, but I was able to get drag and drop interaction working on OSX. (Thanks to Seb Hollington for helping with the coordinate transformation stuff.) Now the editor lets you assign textures by dragging them onto texture slots, just the same as on Windows. There's one last step before the editor code becomes totally platform-agnostic. A file system watcher needs to be implemented on Mac. On Windows, this was fairly straightforward, because there is a built-in API for detecting all files events. OSX has something called FSEvents, but they only detect changes to a directory; they don't actually tell you what file changed, or how it changed. QT has a file system watcher, but from what I can tell, it looks like it doesn't detect new folders that get created. I think this is something I am going to put off for now and slowly research it. As can be expected, OpenGL support on OSX Lion has some issues to be worked out. I haven't actually had a confirmed bug where the driver's behavior is violating the specification, but there are some weird things. Due to the difference between Mac and Windows file paths, I was accidentally not attaching any shader objects to a shader program, yet it successfully linked! This actually does not contradict the OpenGL specification, but ATI and NVidia drivers would have raised an error. The commands for MSAA textures are working, but the highest supported multisample level is one, meaning no multisampling. Again, this is all in accordance with the OpenGL specification, but the GPU in my iMac is capable of doing 16x MSAA textures. I got around a few issues and sent Apple a demo of LE3 running on Lion; The rendering flashes on and off every few seconds, and I have no idea why that could be, but there's nothing more for me to do on it since it's not raising any errors. I think Apple is moving in the right direction, and they'll eventually get things worked out, but I would not recommend buying a Mac for high-end graphics just yet. I met with an Android developer yesterday about getting LE3 running on Android devices. Since we already have it running on Windows, OSX, iPhone, and iPad, adding one additional platform should not be too hard at this point. Compiling C++ for Android is a pretty complex task, so it makes sense to have someone else work on this area while I focus on the core engine and editor. Once we have it running, the "platform milestone" for LE3 will be reached, with support for all platforms we intend to target at launch.

The ordering system problem has been resolved. -The ordering process features 100% SSL-encrypted content, which will display in the browser. -Customers can enter the CC info right on the site and order through our merchant account, instead of sending a PayPal payment. -Customers can order with an account balance, and the seller can still request a payout for the amount earned. -Sellers are protected from refunds because the transaction is governed by the same rules as a regular credit card purchase. Only in case of proven fraud is a refund issued. By contrast, a PayPal account lets the buyer requests a refund within 30 days for any reason, or no reason, and since no UPS tracking number can be provided, the buyer automatically gets their money back. The Leadwerks Asset Store will be launched August 9th. I am composing a press release which will be sent out to tech magazines, bloggers, and journalists so we can maximize your exposure. We’re also launching a promotion for the month of August. All new licensees will receive $20 account credit in the Asset Store. They can use this credit to purchase your assets, and you can request a payout in real money for your balance earned. You may begin submitting your models now, and they will only be visible to you. On August 9th your paid items will all be approved for the launch. If you need to review the terms of the merchant agreement, all information on this program can be found here: http://www.leadwerks.com/werkspace/page/merchants

I've done stuff like this before. Basically, anything that uses the normal to change the shading will break up the flat look.

It's not an "optimization", it's backwards technology for obsolete hardware. Ah well, at least I still get my hardware tessellation...

I seriously doubt you would need to do any of your own culling techniques like this. If a light is hidden behind a wall, it won't be drawn. The cost of each additional light is very low. The shadow rendering optimization in LE is very advanced. There's an article here that explains how to get the most out of it: http://www.leadwerks.com/werkspace/page/Documentation/LE2/tutorials/_/artwork/tools/indoor-lighting-optimization-r18

Occlusion culling is already used on lights and animated models.

Use Visual Studio 2008: http://www.leadwerks.com/werkspace/files/file/215-visual-c-2008-express-edition/

The problem with that is it's never enough. Any time I have released game examples of what you *could* do, they get treated like they are chiseled in stone, and then I get complaints that my example doesn't support X feature. What's needed is a complete rethink of how games are produced, because it's obvious that programming has failed as a design method.

There are ways to do simple water. We made a custom stream shader for the GDC2010 video. It's not that hard to do with refraction or a cubemap for reflection, but it's not supported "out of the box".

You actually can search the documentation, but it's not as simple as I'd like: http://www.leadwerks.com/werkspace/index.php?app=core&module=search&search_in=ccs The index here lists every page: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/index/

The command reference is here: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/ We're not ever going to use CHM again, since it's Windows-only.

Water in LE3 will be done using CSG solids, so you can create multiple volumes of water.

Your card should support occlusion. It will also say so at the beginning of the program .log file. You can turn on "extra statistics" in Options>Display. This will show the number of polygons drawn, so you can see it change. I just created a box car and hid behind it, and I could see the polys rendered decrease.

I just didn't think it was that relevant.