Icons for Inventory System

[SneaksieDave]

Ah well, I might as well put my foot in it again. I thought models would be best from the start for the reasons of ease (don't need to also produce an icon) and capability (like particles, rotating, etc). I shaddup about it because I thought it wasn't trivial, but if it could be done easily enough, why not.

 

Edit: not so sure about the jaggedness thing - AA or desktop resolution should do what it does to handle that, regardless of model size.

[Springheel]

Oh, to add another problem with using models...only .lwo models are supported in guis, which means any .ase models we have would have to be converted before they could be used.

 

Besides that, won't these models and particle effects have a framerate hit as well?

[New Horizon]

Oh, to add another problem with using models...only .lwo models are supported in guis, which means any .ase models we have would have to be converted before they could be used.

 

Wouldn't take long. Just a 5 minute or less batch conversion in Deep Exploration.

 

Besides that, won't these models and particle effects have a framerate hit as well?

 

Meh, shouldn't be that much.

[SneaksieDave]

LWO only?? What the hell... what's the reason behind that?

[Domarius]

I'm assuming it would have been more work to add support for it, and they didn't see a need for it.

[New Horizon]

I just swapped a few of our higher poly models into drumple's T2 style hud and they look really nice. I'll post a screen after I adjust them a bit.

[SneaksieDave]

I don't understand why it'd be extra work, when the game already supports ASE.

 

Gildoran had specifics about the problems using models in the GUI, but maybe there's a way around it? I dunno. Looking forward to screens anyway.

[sparhawk]

They don't HAVE to be transparent. But people decided they wanted the option of them being semi-transparent.

 

I think this is not a really strong point, if the option is to put much more work into them.

 

Enough that it was put in the design documents, and enough that both times we discussed whether to use models or icons, we chose icons (even after SD brought up this very issue). But hey, that was before any work was put into it. The best time to change our minds seems to be AFTER someone goes ahead and spends time working them.

 

Yes. Because then we can see how practicable it really is. Sometimes something seems to be sensible but in practice it doesn't work out as expected, and sometimes it's the other way around.

 

Gil: Icons are easier to work with

 

The problem is that this is true. but only from the programmers perspective, which is not the best choice of perspective. After all, we put all the work on the mappers and our artists, by requiring them to create an icon for each and every potential model that is supposed to go into the inventory at some time. I don't think that this is a good idea.

 

Dram: Models at that size will look like crap without AA on

 

I'm not sure about this either. Most inventory items are rather small by nature, so there is not that much difference anyway. Bigger models might have such an issue. But that that doesn't adress the main point which is the manpower required to create all these icons in the first place. And to be honest, personally I think that the models look much better than icons, because they look rather cartoonish to me.

 

The issue that we have is, do we trade a massive amount of manpower for cerating the icons versus having (maybe) worse looking models which we already have and can make use of.

[sparhawk]

Oh, to add another problem with using models...only .lwo models are supported in guis, which means any .ase models we have would have to be converted before they could be used.

 

How many ase models do we really have? Most are LWO anyway? And to put a constraint on the mappers saying that a model shuold be lwo if it has a potential for goin in the inventory is a much less stringent constraint then requiring them to do icons instead.

 

Besides that, won't these models and particle effects have a framerate hit as well?

 

We don't really need particles, but about the framerate, I don't think that it really is such a big deal. There are about 2 models at most on the screen.

[sparhawk]

I don't understand why it'd be extra work, when the game already supports ASE.

 

I'm going to test this tonight. Yesterday I already played with the models bringing them in the inventory, and I also think they look nice enough. I only used the health potion as a sample, so it might be different for other models though.

[Springheel]

Well, we'd need to know whether it's possible to do the following things with renderDefs:

 

Can a relative scale be set up when the models are displayed? If we just make a 50x50 box to display the models at scale, then the lockpicks will be so small as to be useless (or books and other large objects would be ridiculously large. Icons allow you total control over the size and scale.

 

Two, is there any effect that would allow models to be visible against both dark and light backgrounds? I haven't seen any. Models can be given all kinds of visual effects for this purpose.

 

Three, will large models, shrunk to a very small size, look good, and be easily distinguishable? Many of the TDS models looked like crap when they were shrunk to a small size. Again, this isn't a problem with icons.

 

If we're using renderDefs, we can't make the models transparent (which means the only way to make them less obtrusive is to make them smaller, which looks like crap), which means that they also can't fade out as you scroll through them the way Gil originally had them set up. Icons can easily be given animated material effets, like the lantern opening and turning on.

 

Additionally, can you set up a renderDef to use a model with a different skin? I've never seen anything like that used, but if you can't, that will mean every alternate skin will have to be made into a separate model that can be called.

 

Is there a way to automate the creation of renderDefs? Currently, a mapper just has to make an icon and add one line to a entityDef entry. To create a renderDef they have to understand GUI scripting, as the lighting, orientation, size, etc, is set in the gui code.

 

If we can solve all those problems, then models are the way to go.

[sparhawk]

Can a relative scale be set up when the models are displayed? If we just make a 50x50 box to display the models at scale, then the lockpicks will be so small as to be useless (or books and other large objects would be ridiculously large. Icons allow you total control over the size and scale.

 

That can be done by setting appropriate view offests, which our code will read and set as variables on the models. That would still have to be done by hand for each model probably, but I think that's easier for someone to setup, then drawing a nice icon.

 

Two, is there any effect that would allow models to be visible against both dark and light backgrounds? I haven't seen any. Models can be given all kinds of visual effects for this purpose.

 

Using a background rectangle. You could create a kind of frame for it, so that it's not just sitting there.

 

Three, will large models, shrunk to a very small size, look good, and be easily distinguishable? Many of the TDS models looked like crap when they were shrunk to a small size. Again, this isn't a problem with icons.

 

How large would they be? Of course a shrunk model would look like crap, but in such cases we could specify another model that should go in it's place. This would have to be done for only a smaller number of models though, so it would still work ok.

 

If we're using renderDefs, we can't make the models transparent (which means the only way to make them less obtrusive is to make them smaller, which looks like crap), which means that they also can't fade out as you scroll through them the way Gil originally had them set up. Icons can easily be given animated material effets, like the lantern opening and turning on.

 

I'm investigating this, wether there isn't a way to make them transparent.

 

Additionally, can you set up a renderDef to use a model with a different skin? I've never seen anything like that used, but if you can't, that will mean every alternate skin will have to be made into a separate model that can be called.

 

I don't know you can test it and see if it works.

[Springheel]

hat would still have to be done by hand for each model probably, but I think that's easier for someone to setup, then drawing a nice icon.

 

Just so nobody is operating under false impressions, these icons aren't being drawn by hand! I open the editor, take a screenshot of the model, rotate it and add a few layer effects. It's not rocket science.

 

It doesn't take long at all to make three or four new ones, which is pretty much what a mapper might expect to add. It's just making the first twenty or thirty that's unappealing, because it's drudge work (and because I've been putting a lot of thought into lighting and camera angles).

 

I don't know you can test it and see if it works.

 

There's no way that I currently know of--the renderDef just points to a model, not an entity, so only the default skin is displayed.

[sparhawk]

Just so nobody is operating under false impressions, these icons aren't being drawn by hand! I open the editor, take a screenshot of the model, rotate it and add a few layer effects. It's not rocket science.

 

Aha! That's the reason. As I said already in some other posting, I think they look quite cartoonish. Maybe that's the reason. I think in order to produce good icons, they would certainly have to be manipulated manually at least.

 

There's no way that I currently know of--the renderDef just points to a model, not an entity, so only the default skin is displayed.

 

I think I found a way to set the transparency. I'm going to test this, but it could work. And I think with the same method it might work to use skins as well.

[New Horizon]

I think I found a way to set the transparency. I'm going to test this, but it could work. And I think with the same method it might work to use skins as well.

 

Sweet, hope that works spar. It would be nice to have that option. The icons do look well done, I'm certainly not diminishing your work Spring, I just think the models would give it more of the classic Thief look.

[Springheel]

I think they look quite cartoonish. Maybe that's the reason.

 

I'm not sure how screenshots of the actual models can look 'cartoonish', but whatever.

 

If the problems I mentioned above can be solved, then that's great, let's use models.

[sparhawk]

I'm not sure how screenshots of the actual models can look 'cartoonish', but whatever.

 

Maybe it's the black border which looks like a cellshader?

 

If the problems I mentioned above can be solved, then that's great, let's use models.

 

I'm, looking into it. My first idea didn't work. But I have another idea which might.

 

I tried to make a material for the health potion that is transparent, but somehow it doesn't work, because I don't know well about the materials.

[New Horizon]

I'm curious. Ascottk, how did you make part of the water arrow sack transparent, was that just in a material shader? If so, then transparency should work..because the arrow renders properly in the hud. I could be way off though.

[sparhawk]

Transparency works in the hud. The problem that we have to tackle is to manipulate it from the code.

[Springheel]

Yeah, if the model was semi-transparent in a map, it would also show up semi-transparent in the gui (so I've heard...never tested it myself). But taking a model that is solid (like ours are) and making it semi-transparent is the problem.

[New Horizon]

Yeah, if the model was semi-transparent in a map, it would also show up semi-transparent in the gui (so I've heard...never tested it myself). But taking a model that is solid (like ours are) and making it semi-transparent is the problem.

 

Yeah, the ability to swap skins would be good in that case.

[ascottk]

I'm curious. Ascottk, how did you make part of the water arrow sack transparent, was that just in a material shader? If so, then transparency should work..because the arrow renders properly in the hud. I could be way off though.

Yeah, I just checked the texture & it has no alpha so it's in the shader:

models/weapons/waterarrow/waterarrow_tip
{
glass

//twoSided
noSelfShadow
forceShadows
deform turbulent sinTable 0.0175 (time*0.5) 10
{
		//vertexProgram heatHazeWithMask.vfp
		vertexProgram heatHaze.vfp
		vertexParm 0 time * 0.3 , time * 0.5
		vertexParm 1 1.5
		//fragmentProgram heatHazeWithMask.vfp
		fragmentProgram heatHaze.vfp
		fragmentMap 0 _currentRender
		fragmentMap 1 textures/sfx/vp1.tga
		fragmentMap 2 textures/water_source/vp_water.tga
}
{
	blend filter
	map	models/weapons/waterarrow/waterarrow_tip.tga
	zeroClamp
}
}

I just copied that from one of the water shaders. The rest of the water arrow (& other arrow) textures do have an alpha channel so you can see through parts of the arrow head.

[Ishtvan]

I don't see what the big deal is about "doing more work" to make icons. Like Spring said, it's basically jus taking a screenshot of the model. If the FM author has already spent hours making a new model of something, I don't think they're going to be daunted by taking a screenshot of it for the inventory.

[sparhawk]

That transparency doesn't work anyway, and so wont skins. I don't agree that transparency is really an issue, but the skins could pose a problem indeed.

[Springheel]

Skins would be a very significant problem. If the inventory doesn't support skins, mappers will either have to make multiple copies of models unnecessarily (there will be multiple versions of our loot models, not to mention the 20+ skins we already have for readables), or they'll have to accept that the inventory display won't look like the actual object in the map, which would be confusing for players.

 

That, along with the other problems, would seem to outweight the issues of having to take a screenshot and not being able to rotate it (which seems like the only problems 2d icons have).