1394 replies to this topic

[unclewilly]

Sorry I'm not at home so I can't look at these.
So I could use an alpha image for the map and the transparencey will hold true?

For example similar to how people are doing the alpha flashers, it how jp did his lights in the afm test table

[fuzzel]

You don't need an alpha image. The lightmap is blended with the off-image. It's the same thing you do with alpha flashers the only difference here is that it is static and not dynamic like alpha flashers. So it doesn't replace alpha flashers completely, it's only another way to ease the process of lighting the table.

[unclewilly]

I'll have to look at it when I can be more hands on with it.

I have an idea for a use I just really need to test it to see if it will work

[unclewilly]

Ok another dumb question.

Normally lights use a global texture.

With this it seems you have found a way to map a texture to a light object.

So I guess what I'm getting at would be. Is it possible to create a light object that doesn't use a global texture and is not visible in the off state.

For example, you have a round light insert on the Playfield.

In Photoshop you cut that round insert and make a texture that is just the insert with the square outsiders completely transparent. The you would place that object over the insert in the table and when the object was set to on the new insert texture would show up.

Dies that make sense

[fuzzel]

Yes that makes sense. But instead of just showing the insert, it's add. blended over the off-image.

[unclewilly]

Could you make the object so it wasn't blended but just showed the new texture overtop of the Playfield. Or have the blending as an option

Or a square shaped only light with an imagemodewrap like we can do on ramps
I appreciate all you do for us fuzzel

Edited by unclewilly, 25 October 2013 - 07:56 PM.

[fuzzel]

Hmm I think I let the lightmap as it is because that's the way how lightmaps work The other features you like to have will come with an extra flasher element...

 

Just for the records: rev 686 supports sphere mapping for 3D mesh primitives.

[jpsalas]

I just tried the lightmap, and I must say it is a nice idea for the lights. I tried to change some lights in a table and it worked very well. I used fading lights, and I only needed three small lightmaps for each light color, and then I could use my fading light system using the " FadeOldL" routines, which uses three lights to make the fading.

 

I think it will save a lot of work in photoshop, and in VP it is not so much work to add an extra light. But if you don't want to use fading then it will be much faster and the results are quite good For modern tables maybe fading is not necessary.

[kiwi]

When I enable the Static Rendering for a primitive object,
FPS come down from 1600 to 400 and a ramp 2-3-4 wire disappears.
Same test done with another primitive object and only the FPS decrease the ramp 2 wire is visible.

 

Thanks

 

Max

[fuzzel]

That is a bit vague...can you give some more details?

[kiwi]

This is just a test I did with the revision 686, I don't need to convert to static objects the ramp on the left.
The ramp on the left is made ​​with two primitive objects, wires and rings, when I enabled the static rendering for rings, frames are dropped instead of increasing, and the ramp wire to the right is missing (Standard VP ramp 2-wire).
Same thing if I enable static rendering for the second primitive object, the frames decrease, instead of the ramp right is visible.

 

 

Thanks

 

Max

[fuzzel]

that won't work here. you can try playing around with the drawing order but as soon as the ball rolls under the rings the ball will vanish a bit. Static prims are like walls, pre rendered and if you change something dynamicly it will look strange

[kiwi]

The left ramp is motorized and moves like a clock lancet , must not be a static object.
Is only a test I did to see what happens converting a primitive object to static .
Perhaps the static rendering works well with 3D Mesh, I have not tried this.

 

Max

[fuzzel]

It shouldn't make any difference if you use static rendering with meshes or standard primitives. The basic idea behind that is, that at the beginning when all walls, spinners, flippers and so on are pre-rendered the static primitives are pre-rendered too. After that there is no update to a static primtive anymore. But here you can get problems if you build a non-alpha ramp over the playfield and add a static primitive to it (e.g. a ring or something else) you have to be sure that the drawing oder is correct. Otherwise the static primitive might be rendered first and the ramp second. Alpha ramps are again different as those elements are dynamic (means it will be drawn every frame). My only advice here is try and error There are so many factors which can have an influence to the drawing that it's hard to tell what's the best way or scenario to use static primitives.

[kiwi]

Thanks for all the explanations, but I trying to say that in my PC, the primitive objects not static, work better than static ones.

 

Max

[jimmyfingers]

The performance does what would be expected and stays high when the static primitive is set if neither RU nor RO is selected in the video options. With RU and both RO selected it behaves the way kiwi describes. With just RO, on it stays at it's lowest whether static or not.

 

My experience has been that the best performance for every table I've tested is also with this these settings of no RU nor RO and only having Hardware acceleration selected (lucky for me I suppose being able to use and benefit from static primitives as they stand currently implemented). However, as I've mentioned in several posts attempting to inform people (mainly for the authors / modders / table releasers) - seemingly in vein - that unless you really expect the table to be used for Stereo 3D viewing, that the flasher halo / additive alpha ramp objects should be set to the option "Normal 3D Stereo.." as that fixes the flasher graphic / solid colour glitches and negates the need to turn on RU and RO in the video preferences. This method of fix would indeed throw off the view if actually using a 3D monitor and matching glasses with the other appropriate VP settings, but how many users are actually using that feature vs. how many now having the problems with solid flashers requiring global video preference changes otherwise.  If the authors / modders were to make the changes as described above on the appropriate objects on their respective tables, people would not need to be playing at all with RU and / or RO to fix these graphical issues on the additive alpha enabled ramp objects.

 

Maybe with these video preference settings (hardware acceleration only) now seemingly looking required to benefit from static primitives, people releasing alpha heavy mods / tables will start to shift in where the "fix" / setting on the ramp objects themselves is made, making it easier on end users rather than forcing a particular video preference setting in order for the table to be displayed properly. 

Edited by jimmyfingers, 27 October 2013 - 09:56 PM.

[jpsalas]

I got a strange bug while I was testing the new lights. I made several "lightmaps" in different colors and I added those "lightmap" lights to the TOTAN table. I also removed all the GI walls/lights/bumpers and I deleted all the old playfields and light images. The size has been reduced very much, but a bug crawled in: the flippers turned black. I'm not sure what went wrong, I have tried deleting the flippers and add them again, but they look the same, just black. But the lights look quite nice

 

 

I just wonder if you also see the black flippers.

 

Those lightmaps are nice since you may move the light's cross to where you want to be the center of the light.

 

JP

 

 

[fuzzel]

Nice one JP! I get the same black flippers here, I think it has to do with some wrong render states...will look into it!

 

Edit: Found the bug and fixed it in rev687

Edited by fuzzel, 28 October 2013 - 07:11 AM.

[toxie]

Just one more random idea (who knows when i will have the time to really contribute again though :/):

Would ambient occlusion be helpful to have instead of the super-hacked up static shadow?

 

It should be hopefully pretty easy to include that into the source, but will increase the pre-processing time by maybe 1-2 seconds (depending on system)?!

[fuzzel]

Toxie: That would be cool

 

@all:

Please try rev 688. I added 3 new modifiers (ObjRotX, ObjRotY and ObjRotZ) to the primitive element. With this setting you can set the basic orientation of a primitive. The old rotation/translation settings rotate/translate the primitive around the orientation defined by ObRotX/Y/Z. With this you can animate primitives like the THING in TAF or the wheel in Hurrican