Path: chuka.playstation.co.uk!news From: "Mario Wynands" Newsgroups: scee.yaroze.freetalk.english Subject: Re: Dynamic Texture Changing Date: Wed, 19 Jan 2000 21:45:37 +1300 Organization: PlayStation Net Yaroze (SCEE) Lines: 35 Message-ID: <863tlo$8ku1@chuka.playstation.co.uk> References: <3880CDAA.87D5513@which.net> <388207D8.8826ECED@which.net> <38838fe2.3399055253@news.playstation.co.uk> <3884BE6C.1928D403@which.net> <3884cb4d.3545346658@news.playstation.co.uk> NNTP-Posting-Host: p58-max9.wlg.ihug.co.nz X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Steven Osman wrote in message news:3884cb4d.3545346658@news.playstation.co.uk... > Max, > > The question is, when does the model get sent to the rendering engine? > If you change ONE copy of the model, and then ask the scene to be > rendered, you run the risk that all objects will use the latest > incarnation of the model. > > What I'm getting at, is whether or not NY duplicates an object each > time you call SortObject. If it does not, you'll find that you are > messing them all up. If, on the other hand, sortobject really does > duplicate the model data, then you're okay. It does duplicate the model data. SortObject creates GPU new primitives in a primitive buffer which are hooked into your ordering table. So changing the texture info, calling SortObject, changing the texture info, calling SortObject... will produce the desired result. However, SortObject does not store actual texture pixels with each primitive, only the info on where to get the texture when the GPU goes to draw the polygon. Because of this the idea of copying over the current texture for the model with a new texture in VRAM in between calls to SortObject will not work. Regards Mario mario@sidhe.co.nz www.sidhe.co.nz