Re: [K3d-development] CVS release notes - K-3D 0.3.0.13
Brought to you by:
barche
From: Timothy M. S. <ts...@k-...> - 2003-03-31 02:55:14
|
Ed Millard wrote: > On Sunday 30 March 2003 03:44 am, Timothy M. Shead wrote: >>* Another item I forgot to mention from awhile back - pulled texture >>support from the editor view. Before anybody freaks out, I'm not saying >>we can't have texture support, just that - as discussed publicly awhile >>back - providing useful visualization of textures is gonna require >>something like realtime OpenGL support for RenderMan Shading Language >>(which has, unfortunately, some fundamental differences with OpenGL >>shading language) in all but the most trivial of cases. > An argument could be made that there are a lot of uses for k3d where hardware > texturing is very useful and Renderman is less so. Game developers are a > very large potential audience who don't need Renderman yet but who do need > and want hardware texturing and some multipass support. People who use 3D > paint to create parts of their scenes and characters are another. I've been > toying with a DEM loader and an elevation map node where hardware texture map > support is also desirable. > > In general it is always nice to have a 2D image file shader, some basic UV > mapping control and hardware rendering for a lot of applications. Ideally > scenes using these capabilities should render OK too. No argument, here - this move is more about making a clean break with our pre-RenderMan past than anything. I had already been thinking about the special-purpose-render-engine case (of which games are a subset). Say you want to author content for a specific render engine, say, Quake 3. In this case, you would: * Learn the specific shading model for that engine, e.g. for Quake 3 it's probably something along the lines of pixel = (light map + 0..n bump maps) * texture map + specularity map. * Create a new material plugin for that engine, call it "Quake 3 Material", that contains only the state/UI appropriate for that model - in this case, you'd have a UI where you can select each of the texture maps in turn. * Since this is a multipass shading model, you might-or-might-not be able to implement it within the constraints of the existing editor render engine - if not, create a render engine, "Quake 3 Engine" that can work with alongside Quake 3 Material to produce realistic (in this case, realistic means "what you would see within the game") images. * Optional - write a special RenderMan shader that implements the Quake 3 shading model - this will be easy to do, since RenderMan shaders are written in a general-purpose language. Use this special shader from within your Quake 3 Material whenever the user renders with a RenderMan engine, and your high-quality RenderMan output should resemble (and be controlled by the same parameters as) the game engine. Cheers, Tim |