Josh

A lot of times complex systems will run okay with small amounts of data, but if performance scales in a linear manner as the amount of data increases, you will have much worse performance than if you do something clever to change the way it scales. This is true of both 3D graphics and database applications. In 3D graphics, we do things like clustering objects in an octree so that large numbers of objects can be discarded without iterating through them all. In database applications, they do stuff like caching and who knows what else to make applications scale in a non-linear manner. I can't say exactly how database applications are designed because it's not my area of expertise, but there's a lot of work that goes into it.

I believe you could set up a very rudimentary system in two days, but a fully-featured system that scales well would take a very long time to learn and develop.

I generally categorize every aspect of Leadwerks as either "absolutely required" or not necessary. If it's categorized as the latter, I don't bother with it, and if it's categorized as the first, I pursue it with a dogged determination until it is done. This has served us well in many ways, like our vegetation rendering system and character controller. However, this assumes I have full control and mastery over the product, or at least have someone working for me who does. This is almost always the case with software development. I do not have the same power over other aspects of Leadwerks like the website. Our bug reporting system, based on IP.Tracker, was an unsupported unofficial add-on offered by Invision Power Services. That means they offer it, but if anything goes wrong you are on your own. This should have steered me away from using it. I generally never use any third-party add-ons, especially free ones, but the features were nice and it was compelling. (The one exception in our system is our chat system, which has functioned wonderfully, but also came with a fairly high price tag. Correlation?) After installing IP.Board 3.2, I attempted to install the new Tracker that works with it, but the installation process would not work. I even got IPS to look at it, despite their policy of this being a non-supported product, but their "fix" was quickly done and didn't actually fix it. I could keep pestering them, but I've already spent a lot of time on it, and we're never going to get a real solution. Even if it could be installed successfully, a new problem could arise at any time, and we'd be back in the same position as before. The application hasn't been updated since August of last year even though there are outstanding bug reports. Despite all it's complexity, there's really no other forum/CMS that comes close to the features IPB offers. Anyways, the point of my long-windedness is that I'm giving up on upgrading IP.Tracker and created a bug report sub forum here: http://www.leadwerks.../59-bug-reports The data is all in the database still, and there's a possibility we might be able to migrate it into the forum, but I honestly wouldn't count on it. The value gained per unit effort is getting very bad if I keep going down this road. Additionally, the new IP.Gallery application is so badly designed I consider it unusable. Even before the upgrade, people frequently posted images in the Showcase forum rather than deal with the complexity of managing albums and uploading images into different categories. I have implemented a custom system here we have complete control over. I encourage you to re-post your images here where they will be safe, and I have complete control over the layout and design: http://www.leadwerks...ce/page/gallery I have posted a few images there to test with. If I posted one of your images and you would like to re-post it in your own name, I will gladly remove my upload. Additionally, the latest images will soon be added to the Portal page, mixed in with the latest videos thumbnails. A link to the old gallery will remain at the bottom of the Gallery page until April 1, 2012 so you can access your images. This is a complex site, and I am operating it with a minimal amount of IT support. Going forward, we are going to implement a few policies to minimize problems. 1. No third-party applications or features will be utilized, with the exception of our chat bar, which is a paid third-party product that has always functioned perfectly. 2. When a custom database can serve our purposes, that will be preferred over third-party applications and even some official IPS applications. For example, I implemented a custom database for the video section, articles, and replaced IP.Gallery with our own system. (I do not have any plans for any additional databases or website features in the near future.) The upgrade to the latest version of IP.Board was well worth it, in spite of those couple of problems. First, it would have been very difficult to find a designer capable of and willing to work with the old version. Second, the new system cleans up a lot of the functionality of the older version, which oould be quite chaotic in some places. Finally, it ensures we are up to date if any security issues should arise. There hasn't ever been any, and I have no reason to believe there will be, but it's best to be prepared. IPB 3.1+ was really an infant product compared to the more mature version 3.2. Further versions of the system are not expected to be such drastic changes, as the feature set and design has solidified quite a lot. Thank you for your patience and especially for generating all the great content that makes this site so fun to browse.

This says that card has 96 stream processors ("CUDA Cores") and a gig of VRAM which should be good, but your performance seems dismal for some reason, in everything you have posted. My frame rates with an old GEForce 9800 in the arctic scene are 60 FPS, I think. http://www.geforce.com/Hardware/GPUs/geforce-gt-530-oem/specifications You're sure it's not a GEForce 520?

The master speaks.

I know what's going on... Since your framerate is below 60, the physics are being updated multiple times per frame. After an update, the force is reset to zero. If your framerate is 15, the force gets carried out on the first physics update, but does not on the next three that occur before the world update function finishes. It's better to call any physical functions like this in an entity or world physics update function, so it always gets called before each physics update occurs.

I can't immediately.

I changed my response since I don't see anything wrong with your code.

That does seem strange.

Gravity is a constant force of 9.8 meters per second squared. Gravity causes objects to accelerate. If you want a constant speed use CalcBodyVelocity to figure out the required force.

There's no way your FPS should be that low unless you have some setting really massively off. Distance culling would be the most obvious issue.

At the point materials and shaders are enabled in the rendering pipeline, the code has no idea what entities are being drawn. All it has is a 4x4 matrix. Materials are not enabled per-entity. They are enabled once for each batch of surfaces drawn.

Yep, that's why everyone is just installing straight to the C drive nowadays.

Turn on SSDO, make your ambient light dark desaturated blue, make the sunlight slightly orange and crank the intensity up, enable HDR, and that will look fantastic.

There's not necessarily even an entity associated with every material. I would use the entity draw callback for anything that needs the entity.

Sorry, the docs were wrong. There is no second parameter in the callback: http://www.leadwerks.com/werkspace/page/Documentation/le2/_/command-reference/materials/materialdrawcallback-r295

You don't have to redo anything, just click the option and it will work.

It looks like your text resolution is really big, but I don't see how that would make a difference. Go to Help>About and it will show the version of the program.

It should look like this:

I have done much denser scenes at a high framerate. It's hard to tell how far off the trees are visible, and how dense they are. Distance culling is your friend. The smaller a plant is, the nearer the distance culling should be. This can make the difference between unplayable and good frame rates. It also appears you are attempting to fill the emptiness of the scene by adding unnaturally dense trees in the far distance. Ground cover will do a better job of this, and can be distance culled with no visible loss of quality. Add more bushes and rocks to fill up the empty forest floor. If you had twenty rocks visible onscreen, it would make the scene look like a real forest, and the rendering cost would be very little. Billboards can make trees in the distance cost pretty much nothing to render. There's a setting for the billboard distance in the vegetation options.

I experienced this in pure depth-calculated approaches because there was no way to know whether the face was angled, or if it was on an edge with another pixel next to it, further back in the depth buffer.

Incidentally, the reason Crysis SSAO tends to shade object faces for no reason is that because Crysis is a forward renderer, they have no access to screen normals data in the post processing pass. That's why Lord Hippo's SSAO looks better.

You mean CPU, right?

In normal usage culling will result in a massive improvement to otherwise unplayable framerates. If you pack thousands of entities into a small space, of course performance will be bad. It's fine for polygon counts to be high, but you should keep the number of passes / meshes as low as possible. This is the nature of modern graphics hardware.

It's working as I would expect. Culling has a cost, but typically also results in savings because entities get skipped. If all entities are onscreen, there will be no savings to balance this cost. It's drawing a lot of meshes for the shadow render. The directional light shadow does not just render what you see, it renders anything the directional light sees that might cast a shadow into your field of view. An object can be offscreen, but still cast a shadow that falls onscreen. The directional light shadow renders three passes for the different light volumes the shadow uses. If you disable shadows you will see that the number of entities drawn corresponds perfectly to what you see onscreen.