Per-object textures for s3o

[Pressure Line]

very. Quant has mentioned he knows how to fix the problem with the extras not being rotating with the unit, he also said he is busy, so assuming i dont manage to fix it first, should have a slightly more usable version in the upcoming week(s?)

so yeh, the roadmap at the moment is to fix the rotation of rendered extras, then move onto improving portability.

a thing to note is, that as far as i can tell, because its done directly in OpenGL, the system supports proper transparencies ^_^ this will also be invesigated.

[Tobi]

It's depth (z) buffered, just like most other world stuff.

a thing to note is, that as far as i can tell, because its done directly in OpenGL, the system supports proper transparencies ^_^ this will also be invesigated.

You'll face problems with rendering order, I guess. Though as long as you render transparent geometry after normal geometry and you never have overlapping transparent faces stuff will be alright. (Meaning it will be hard (impossible?) to make it possible to watch through a transparent unit at another transparent unit without visual artifacts.)

[Pressure Line]

update!



Version 2 availible here. This fixes the issue from the previous version where the rendered parts wouldn't follow unit rotation.

now taking votes for the next stage:

*option 1: improve portability

*option 2: animated parts controllable via .cob

[AF]

both options could be done along with about 100 others if those where proper units rather than OpenGL rendered via lua.

[Pressure Line]

feel free to do it yourself then AF. seriously, im just mashing together functions and calls at the moment, i have no idea what im doing (ask jK for verification of this)

but im doing something. which is a start.

[AF]

from what I understand of it, you would be more at home doing the unit method rather than heading for the OpenGL method, and I've already explained why I cant do it, I simply dont have the time and resources for yet another project.

[Pressure Line]

sorry bout that post. aircon was busted at work, and it was like 100*F.

actually, using empty objects to control the movements and positions of the lua-drawn parts is exactly what i was after anyway :) to be specific the system needs to be as simple to pick up as possible. having it all controlled in exactly the same way as a regular 3do/s3o model means it becomes a lot easier to: 1) integrate into an existing project, and 2) become part of a new project started by a relative modding newbie.

once i get a properly configurable version out I intend to embark on a project to get a some vehicle and weapon models out there for people to download and use as the basis for their mods.

[Argh]

I really like the sound of this. When you have some code that runs reasonably fast, I'd like to test it and help document it. I would say that I'd help code it, but I'm tied down with a billion other things unfortunately. I like that you're giving this a serious go, though, it could solve a lot of problems if it runs fast.

[Pressure Line]

well as for speed, using the test mod i spawned 500 of the test units.

AMD Semperon @ 1600MHz
512MB RAM
GF7300GT AGP

I lost 1-2 fps between having the widget enabled and having it disabled. and tbh i feel thats acceptable for the engine having to render a lot more geometry per frame. i could run a comparative test with a unit that has the extras included as part of the original model, but i cant be bothered to do that to test out a 1-2fps framerate drop on an outdated system.

[MadRat]

Outdated? Hell its better than all but one of my systems in the house. :)

[Pressure Line]

*works some necromagic*

I am still working on this. Its proceeding well, not long now until i have fully functional code :)

will update later :D

[smoth]

cool, I was wondering how this was going.

[Pressure Line]

There are a few limitations that im not 100% sure on how to fix with the method that im currently using, one of these being the application of teamcolour.

[Warlord Zsinj]

Hope this comes together well, we need something with a similar function in IW.

[FLOZi]

There are a few limitations that im not 100% sure on how to fix with the method that im currently using, one of these being the application of teamcolour.

Fortunatly S44 doesn't need teamcolour for what he hope to use this for.

[yuritch]

Yes, things like those definitely need multitexturing, but require no teamcolouring:


S'44 needs that to have the best looking ships in a Spring mod to date...

[Argh]

You can't just do that with a single 2048 skin? Even ATi cards will handle up to that size (although I should note you'll kill older cards, performance-wise). But yeah, multitexturing would be awesome, it'd make a lot things possible that aren't right now, or are possible, but are a royal pain in the ass, like mirroring- it'd be soooooo nice, if I could just build stuff and use code to mirror the other halves, or repeat stuff arbitrarily, among other things.

[FLOZi]

We want it because many ship turrets are common to different vessels...

[Warlord Zsinj]

Lack of teamcolour is a shame, I really hope you can get that working.

[Pressure Line]

I am not 100% sure, but I think there is another way of doing straight up multiple textures, but since the spring spec Lua documentation is sketchy at best I have no idea where to even start on it.

The way im doing it uses RGBA textures, with the possibility of reflection and bump-mapping (not normal afaik), from what i can see of the other method it uses the Spring texture1/texture2 system. (which would have teamcolour...)

PS: I can also do OpenGL lighting >_>