Great. I'd rather specify more than one texture or better yet, texture mapping per object without having to use Lua to assemble your model out of lots of seperated s3os. Also, is it confirmed that this won't break scripts?AF wrote:But you can already do that using lua. Have you not seen trepan talk about lua models? At one point eh even said it was faster. Lua does have OpenGL access after all.
Texturing and impact on performance...
Moderators: MR.D, Moderators
Indeed, the lua model drawing isnt a process such as:
Rather its exactly what it is, drawing a model using lua. Theres no mention of animation, there's no mention of units even, the model is just drawn as you said. Its all completely pure lua, no engine callbacks to say the user clicked on your model or Spring.createLuaModel() hanky panky stuff.utter nonsense wrote:Hey this model isnt s3o, it isnt 3do its lua! take this model draw() function command and pass it on to thsi handy lua script!
Well, it still requires:
1. A workflow, whereby the models can be combined. Preferably without having to manually specify origin locations, etc. Something like:
2. A method whereby all COB scripts are called properly (that's the painful bit). So, object MyMultiPartModel needs to refer to the COBs for TankBody, TankTreads and TankTurret every frame, and the parts that must respond to general engine commands (i.e., a call to shoot at something), must respond appropriately as well.
Without these two things, we're left with either objects that rely entirely on LUA to facilitate communications (i.e., a master object to pass state changes to other COB scripts- yuck), or stuff that's being drawn as modules, but is strictly non-active eye-candy.
Making good stuff with complex animations is already a lot of work. I'm not touching this until I see that it's going to either deliver significant time-savings on my workflow, give me major new functionality, or radically change performance.
1. A workflow, whereby the models can be combined. Preferably without having to manually specify origin locations, etc. Something like:
Code: Select all
objectName=custom:MyMultiPartModel;
[MultiPart]
{
part0=custom:TankBody;
part1=custom:TankTreads;
part2=custom:TankTurret;
}
Without these two things, we're left with either objects that rely entirely on LUA to facilitate communications (i.e., a master object to pass state changes to other COB scripts- yuck), or stuff that's being drawn as modules, but is strictly non-active eye-candy.
Making good stuff with complex animations is already a lot of work. I'm not touching this until I see that it's going to either deliver significant time-savings on my workflow, give me major new functionality, or radically change performance.
-
[Krogoth86]
- Posts: 1176
- Joined: 23 Aug 2007, 19:46
Well I think the recent Inverse Kinematik like system is ok for most purposes like aiming and so on but especially for things like K-Bot leg animations and things like that we need real GPU-driven keyframing (a skeletal system would be even better but I think vertex animations would be enough) and especially GPU-driven particle systems (many Nano Towers = crawling game speed)...
