1394 replies to this topic

[toxie]

Absolutely, but i guess not for this release.. We really have to get this out the door now to have a downloadable version for the "normal" users..

[fuzzel]

I think it would be great to have a flasher/light component. Now we are using ramps for the GI and flashers, Wouldn't it be better to have a specific component to do this? and leave the ramps as they are now. That component would be square and we could change the image and/or opacity just like we're doing right now.

this on my personal todo list for 9.3, but now as toxie said we need to get 9.2 out of the door

[toxie]

As said, i'll look into this one more idea i have, and otherwise i'll guess we have to stick with the current behavior as it seems to be the best tradeoff..

 

 

Turns out this idea has the same problems as the behavior before..

So i guess we're really stuck with what we have currently..

 

Apart from that evil ramp issue, anybody else found something with the latest revision in the meantime?

[LoadedWeapon]

Sorry if I missed something but why did we have the changes? I dident have any problems before so what kind of prob did r783 suppose to fix?

Edited by LoadedWeapon, 12 December 2013 - 09:00 PM.

[settingsons]

Maybe we need a ramp abusers support group.
"Hi, my name is Tom and I abuse ramps"
The first step is admitting you have a problem

In a couple of weeks time when you are a 'recovering ramp abuser' you will look back and say it was worth it in the end

[toxie]

Sorry if I missed something but why did we have the changes? I dident have any problems before so what kind of prob did r783 suppose to fix?

If a table didn't abuse the '3d stereo' option in the ramps, but used it like originally planned (or simply left it at default), then nobody had a problem.
Otherwise, depending on the table and the combination of settings of RU/RO/3D, there were different rendering artifacts for such ramps.
Now, with the new rev these problems are gone, but tables that rely on this bug/feature will look wrong until the ordering/height of the ramps is tweaked.

[unclewilly]

Ok I'm finishing up coding the Dracula on monster bash and getting ready to do all the lighting.

So I just want to clarify this.

I don't use ro or ru. So with the new 9.2 that will be released.

What exactly do I need to do with the bilinear alpha ramps for the gi so they aren't just big solid colors. Before I would check the 3d normal box and that would fix this issue.

Just a quick explination please

[teppotee]

I'm also a bit confused which is the correct way to handle the BI ramps with the newest versions.

 

I have this version of AFM on my computer where I have added cabinet reflections to all flashers -> so I this is REALLY abusing the ramp bug I tried to play with different RU/RO and ramp property settings but couldn't get this to work. So is there any way to eliminate the alpha blending problem that is seen in the attachment (using the very latest rev 784)? Don't want to spend more time trying if it's not possible. 

 

 

 

 

 

 

 

Attached Files

•  afmgrapherror.png   634.68KB   5 downloads

[toxie]

if you have the 'normal 3D stereo' box -checked-, then everything is exactly the same behavior as before anyhow (i.e. if it's different, then it's due to some other fix or change).

it's all just about the cases where the box -isn't checked-.

 

 

as for explanations on best practice in real life, i guess koadic and herweh should comment..

 

 

my own -limited- view on things though would be to use ramps for GI/lighting & flashers in the following, convenient, way (which should work in theory for -all- RU/RO/3D combinations, so hopefully all users are happy then as they can still choose freely what to use on their hardware setup):

 

1) enable the region update checkbox on the ramp to make it automatically update the affected regions.

2) turn the visible or alpha flag off via script, if it doesn't flash/light anything to avoid unnecessary redraws.

3) if you use multiple -overlapping- ramps, then make sure that you draw them in order (use the sorting mechanism that fuzzel introduced via the drawing order dialog) and that they have slightly varying height (first to draw the lowest, last to draw highest).

4) if you only use the ramp to do fake lighting (i.e. GI or flash), then -disable- the 'normal 3D stereo' checkbox to avoid problems for 3D rendering.

 

afterwards please test with RU/RO on/off to make sure there are no problems (there shouldn't be any, but who knows, after all it's still not the final 9.2.0)

 

 

hopefully this works like intended, so if there are problems doing it like that, it would be most likely still a bug!

 

 

EDIT: @teppotee: this looks like z-fighting, so try to move the flasher ramp slightly away from the wall (towards the inside). If its that, then this is a common graphics rendering problem though, not specific to VP.

Edited by toxie, 13 December 2013 - 07:07 PM.

[jimmyfingers]

@Toxie - I think one thing on the above I would change; Instead of "enable the region update checkbox on the ramp to make it automatically update the affected regions" I would suggest that it is left blank and instead, if it's to be updated graphically by some event, use the ramp.TriggerSingleUpdate in a sub routine to do similar processing as to what the old light refresh would do to achieve the update.  I only did some quick tests since those options became available, but on my test table when the ramps were clicked with "Update Regions" as a general / overall element, the table performance started to suffer again. If lot's of ramps started to use this it would seem to just get close anyway to being like having RU on in the general settings. 

 

Leaving the ramp "Update Regions" blank but using a routine with the  ramp.TriggerSingleUpdate instead can achieve the same effect and object update without it being in the state the rest of the time with the "Update Regions" being active.  As I  say, I have not done a ton of testing but on the one table I was assessing it with, just 6 flashers with it enabled altered the performance where if I left them not enabled but used a ramp.TriggerSingleUpdate fade / flash routine instead I didn't notice any change and they updated just fine / as expected.

[toxie]

Of course. That's what i meant with the "convenient" part and that this simple way will work for all users, no matter if RU/RO/3D is en/disabled.

As for some users RU en/disabled can be bad performance-wise. And then they could still choose.

 

But apart from that, using TriggerSingleUpdate is of course perfectly fine and most likely the fastest on most systems.

Though i guess what is the best way on the average system will only become clear when more and more tables will be released and more users will do performance-tests.

[koadic]

Hey toxie/fuzzel, as trying to get alpha ramps all ordered correctly is a pain in the butt, is there anyway for VP to just draw them in order of height regardless of how they are ordered in the editor? I can't remember if this has ever been brought up before (most likely has, but oh well ). That way we can just mess with the heights alone and not have to worry about if the alpha ramp at 54 height is drawn below the alpha ramp at 55 height, it just is...

As it is now, if 54 is ordered above 55, 55 disappears.

While the Drawing order dialog is nice to have, sometimes it has an unintended effect on other ramps and it ends up being like a Lights Out game just trying to make sure everything ends up just right.

It only needs to be applied to alpha ramps, and if they are drawn in order determined by their bottom height (again, regardless of the order in the editor), it would help immensely.

[toxie]

Good point.. I tried to include this automatic resorting at some point for all elements, and all hell broke loose, but i guess for the alpha ramps and primitives it can really be automatic!

[toxie]

rev 786 adds this automatic sorting.. i didn't test it much though as i have to go out now, but wanted to get this out for you guys if this is good enough and/or if it leads to other problems on some tables..

[koadic]

just tested on CV, seems to be pretty much ok, but there is one small graphic issue... Any chance of turning this sorting on with a per table checkbox? That way old tables aren't adversely effected, but new tables with this built in mind can enable this auto sorting.

Further explanation with the issue... it seems that the the main ramp that goes from 0 to 130 is getting drawn above a flasher at a height of 51... Does it determine the sorting by the average of the top and bottom heights?

It also has some adverse effects with a couple overlapping primitives I have in another table I am helping with... maybe exclude primitves from the autosorting? or does that throw everything else out of whack?

Edited by koadic, 13 December 2013 - 08:41 PM.

[jimmyfingers]

Yes, please if you can make the autosorting a per table option as I use purposely order "incorrectly" ramps to block flashers overlapping the sides in desktop versions and for several other cases.  I have a number of tables in which manipulating the order "incorrectly" has provided the abiltiy to hide and shape alphas better.  This will be broken now. 

 

I know this may also be considered a hack but it was at leat using the known constraints and behaviour of alpha layering.  A table option could at least be a work around and would be very much apprciated.  It also breaks something on my GI8 AFM table that I'm almost finsihed and have spent tons of time on and in a way that I will have no solution for with the problems with the current default primitive side-mapping texture bug.  The autosorting may also have larger impacts on ramps like in cases where Koaic touches on above.

Edited by jimmyfingers, 13 December 2013 - 09:13 PM.

[fuzzel]

hmm sorting by height is nice but you will get problems if two ramps intersect each other. Today everything in VP is based on the user defined drawing order and I think it gives you much more control than doing it automaticly even if you have to define the drawing order for each ramp...Automatic sorting based on the height would mean doing it for every element and not only for ramps but I would like to leave that for a next version.

[unclewilly]

When can we expect the 9.2 release

[fuzzel]

well if it would just me then I would release 784 as 9.2. I won't change anything on VP until we get this version out, because everything I have on my todo list would mean deep changes and therefore new bugs

Edited by fuzzel, 13 December 2013 - 09:41 PM.

[bent98]

I'd love to know what's on your to do list.