Comments on: Optimized Asset Processing http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/ Game Development and General Hacking by the Old West Tue, 20 Jul 2010 15:03:31 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: kotiteatteri http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/comment-page-1/#comment-107764 kotiteatteri Mon, 04 May 2009 06:50:48 +0000 http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/#comment-107764 I liked the write bad code idea. You'll never have time to do everything and it's sometimes reasonable to write bad code to acchieve what your goals are. Can you actually publish articles that are published in magazine on this web site. I liked the write bad code idea. You’ll never have time to do everything and it’s sometimes reasonable to write bad code to acchieve what your goals are. Can you actually publish articles that are published in magazine on this web site.

]]> By: Scientific Ninja http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/comment-page-1/#comment-82768 Scientific Ninja Fri, 06 Feb 2009 05:02:32 +0000 http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/#comment-82768 [...] ways to alleviate those bottlenecks. This can happen on the large scale — writing tools that automate large, cumbersome processes that used to be entirely manual — or on a smaller scale. Even improving the usability of an [...] [...] ways to alleviate those bottlenecks. This can happen on the large scale — writing tools that automate large, cumbersome processes that used to be entirely manual — or on a smaller scale. Even improving the usability of an [...]

]]> By: Emmanuel Deloget http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/comment-page-1/#comment-324 Emmanuel Deloget Tue, 13 Mar 2007 18:10:05 +0000 http://cowboyprogramming.com/2007/03/12/optimized-asset-processing/#comment-324 I tried to remember the good old days when I was working for the game industry. We had very simple preprocessing tools (mostly for the PS1 version of our game: reorder vertices, pack models and textures and so on). Most of these tools were written with Quick Hack Mode set to ON - that turned to be a bad idea. The artists often had to wait to see their assets in the game itself. Of course, that allowed them to work on another asset, but this is not a good thing in the end - it doesn't help to keep focus, and lengthen the asset tuning process. So I completely agree with this article - and that's a "been there, done that" kind of agreement. Strangely enough, I'm not sure that my opinion is of much interest. Regarding file access and memory management, you stressed the reading part of it. The writing part is at least as important - if the asset processing tools never write anything, that's not going to help a lot - and techniques that are similar to those you presented can be used as well. About multi-processing, it's true that many tasks can be parallelized. If you have to process many models to create an archive, it's probably a good idea to create a thread for each model (up to twice the core count, for esxample). The idea is to try to use 100% of the CPU time. Don't hesitate to play with thread priority as well - there's no need to process the assets at the normal thread priority. Boosting it (say, to a high priority thread) can help a lot and is very easy. This can be changed using a command-line argument if the user of the machine needs to perform other tasks as well. There are many ways to make the asset pipeline more efficient. Use them all - because having to wait for some assets to try a feature is just plain dull and unproductive. Best regards, -- Emmanuel Deloget I tried to remember the good old days when I was working for the game industry. We had very simple preprocessing tools (mostly for the PS1 version of our game: reorder vertices, pack models and textures and so on). Most of these tools were written with Quick Hack Mode set to ON – that turned to be a bad idea. The artists often had to wait to see their assets in the game itself. Of course, that allowed them to work on another asset, but this is not a good thing in the end – it doesn’t help to keep focus, and lengthen the asset tuning process.

So I completely agree with this article – and that’s a “been there, done that” kind of agreement.

Strangely enough, I’m not sure that my opinion is of much interest.

Regarding file access and memory management, you stressed the reading part of it. The writing part is at least as important – if the asset processing tools never write anything, that’s not going to help a lot – and techniques that are similar to those you presented can be used as well.

About multi-processing, it’s true that many tasks can be parallelized. If you have to process many models to create an archive, it’s probably a good idea to create a thread for each model (up to twice the core count, for esxample). The idea is to try to use 100% of the CPU time. Don’t hesitate to play with thread priority as well – there’s no need to process the assets at the normal thread priority. Boosting it (say, to a high priority thread) can help a lot and is very easy. This can be changed using a command-line argument if the user of the machine needs to perform other tasks as well.

There are many ways to make the asset pipeline more efficient. Use them all – because having to wait for some assets to try a feature is just plain dull and unproductive.

Best regards,

– Emmanuel Deloget

]]>