Article on Content Creation
Just found this very good article on Gamasutra regarding content creation tools. It relates specifically to exporting 3D-material from 3D-packages, but it presents some very good generic guidelines for software creation. Some of the points I noticed:
Fast test-feedback is important in almost every aspect of creation - I as a programmer also know it from compile and especially link-times.
This is great inspiration for the tool I'm currently working on (3D accelerated video editing mentioned here earlier). Everything is currently in technology-testing phase, and no GUI decisions have been made yet. I guess the main lesson is to apply the good old KISS principle on the design plans and attempt not to overengineer things from the beginning.
The status of the project is, that beside a lot of learning DX9, I've got some test setups running. I've got basic videotransfer working, so I'm now able to transfer RGB, YUY2 (with unpacking to YUV4:4:4 on the CPU) and YV12 (No unpacking needed) to the graphics card - have it converted to Float YUV 4:4:4, convert it back to RGB32 and displayed at a very reasonable speed. I've also tested readback from the graphics card - Reading back full float 16 is way too slow, but some tricks might be possible here (and 32bpp YUV or RGB is still an option)
I'm still having a few issues with nVidia's cG compiler, but at least I've been able to get a (very slow) GeForce FX 5200 for both my machine at work and at home. So I'm now able to do DX9 Pixel Shader 2.x fragment programs. Performance is not the very best on the FX5200, but these are also very slow cards, so I'm not that concerned with the performance aspect yet.
Doing video as 16bit float seems like a very good idea. My main concern is actually running out of video memory. Efficient caching and usage of video memory is more important here as it ever was. This is also why I've decided to redo the video request method, and implement a "managed" filter chain.
How to handle interlaced material is also something that needs testing. There are three possibilities. I think of right now:
- Your software should never "fail". Always provide good informative, and at best visual feedback of the problems.
- Don't assume artists (and users) think like programmers.
Fast test-feedback is important in almost every aspect of creation - I as a programmer also know it from compile and especially link-times.
This is great inspiration for the tool I'm currently working on (3D accelerated video editing mentioned here earlier). Everything is currently in technology-testing phase, and no GUI decisions have been made yet. I guess the main lesson is to apply the good old KISS principle on the design plans and attempt not to overengineer things from the beginning.
The status of the project is, that beside a lot of learning DX9, I've got some test setups running. I've got basic videotransfer working, so I'm now able to transfer RGB, YUY2 (with unpacking to YUV4:4:4 on the CPU) and YV12 (No unpacking needed) to the graphics card - have it converted to Float YUV 4:4:4, convert it back to RGB32 and displayed at a very reasonable speed. I've also tested readback from the graphics card - Reading back full float 16 is way too slow, but some tricks might be possible here (and 32bpp YUV or RGB is still an option)
I'm still having a few issues with nVidia's cG compiler, but at least I've been able to get a (very slow) GeForce FX 5200 for both my machine at work and at home. So I'm now able to do DX9 Pixel Shader 2.x fragment programs. Performance is not the very best on the FX5200, but these are also very slow cards, so I'm not that concerned with the performance aspect yet.
Doing video as 16bit float seems like a very good idea. My main concern is actually running out of video memory. Efficient caching and usage of video memory is more important here as it ever was. This is also why I've decided to redo the video request method, and implement a "managed" filter chain.
How to handle interlaced material is also something that needs testing. There are three possibilities. I think of right now:
- Maintaining the image interlaced.
- Fieldseparate, use half height and double the framerate.
- Fieldseparate, but bob to full height and thus double framerate.
0 Comments:
Post a Comment
<< Home