1488 replies to this topic

[fripounet]

light source (x, y, z) halo1(or falloff1)
light target (x, y) halo2 (falloff2)
to get volumetric lights in the vr room
a bit like this
possible for vpx11

 

 

 

Edited by fripounet, 02 February 2020 - 01:57 PM.

[fuzzel]

Sure everything is possible only time is the rare resource here...

[onemanproject]

VPX crashed again:

 

crash.txt:

 

Crash report VPX rev3788
============
Process: VPinballX.exe
Reason: 0xE0434352 - UNKNOWN at 0023:75C53DB2
Thread ID: 0x2254 [8788]

Call stack
==========
75C53DB2 KERNELBASE.dll RaiseException + 0x62 (0xFFFFFFFFE0434352 0x00000001 0x00000005 0x22d8b624)
72697155 clr.dll CorExeMain + 0x9245 (0x00000000 0x46F13F9B 0x22D8B7D8 0x18b88254)
726029A4 clr.dll PreBindAssemblyEx + 0x22BE4 (0x22D8B970 0x72602760 0xFFFFFFFFFFFFFFFF 0x0a6d1880)
68060A47 WindowsBase.ni.dll (0xFFFFFFFFFFFFD8F0 0xFFFFFFFFFFFFFFFF 0x00000000 0x00000000)
68070AC7 WindowsBase.ni.dll (0x23DEA834 0xFFFFFFFFFFFFD8F0 0xFFFFFFFFFFFFFFFF 0x00000000)
6823CBCE WindowsBase.ni.dll (0x23DEA7F8 0x00000080 0x18B1C79C 0x18b56504)
1F1480D3  (0x00000020 0x18BB1E6C 0x18B78184 0x18b781a0)
1F1479A4  (0x18B78184 0x00000000 0x00000000 0x00000000)
1F1478B3  (0x18B781A0 0x00000000 0x00000000 0x00000000)
1F1475CE  (0x18B7821C 0x00000000 0x00000000 0x00000000)
1F147504  (0x00001000 0x00000020 0x00000080 0x22d8b95c)
18A617F5  (0x18B83024 0x00000020 0x18BB1E6C 0x22d8b990)
18A610DB  (0x1CABEB88 0x1662D970 0x0C740118 0x22d8ffcc)
0A6FD506  (0x00000080 0x00000020 0x1CABEB88 0x00000000)
1ADFAB2E vpinmame.dll (0x0C537910 0x22D8FDA0 0x00000002 0x1b204284)
1ACF2062 vpinmame.dll (0x00000000 0x00000020 0x0C89F2D0 0x1b1e4768)
1ACFE336 vpinmame.dll (0x000008C7 0x1B1E4768 0x22D8FF70 0x00000001)
1ACF121C vpinmame.dll (0x09583970 0x00000000 0x75A18A60 0x000311c8)
1ACF0F8D vpinmame.dll (0x0F800FF0 0x00000000 0x00000113 0x00000001)
75FC40DE user32.dll DispatchMessageW + 0x22E (0x00000000 0x1584D958 0x1584D958 0x1b1371f4)
1AE5B226 vpinmame.dll DllUnregisterServer + 0xB0A6 (0x1B065DC4 0x1584D958 0x22D8FF70 0x00000000)
1AE5B226 vpinmame.dll DllUnregisterServer + 0xB0A6 (0x00000000 0x09583970 0x75A18A60 0x1ae4977f)

Environment
===========
Date/time: 1/2/2020, 20:11:36:95
Number of CPUs: 4
Processor type: 586
System: Windows 10 (10.0 18363)

Memory status
=============
Total Reserved: 245312K (239M) bytes
Total Commited: 739756K (722M) bytes
Total Free: 3209172K (3133M) bytes
Largest Free: 2095296K (2046M) bytes

Registers
=========
EAX=22D8B560 EBX=00000005 ECX=00000005 EDX=00000000
ESI=22D8B624 EDI=00000001 EBP=00000000 ESP=22D8FF38 EIP=1AE514E3
FLG=00000216 CS=0023 DS=002B SS=002B ES=002B FS=0053 GS=002B


Failed to save minidump.

 

[fuzzel]

Nope not VPX crashed but VPM.

[DJRobX]

 already did this for both VPX and VPM years ago.. The only major thing missing is better SAM support, but this is something that mjr and maybe DJRobX would need to do as i do not have the time to completely get mjrs AT91 JIT implementation and rework it..

(that's also why there is still this annoying bug in the AT91 JIT code which leads to crashes on some setups with JIT enabled)

 

So, apart from that, this is all finished..

 

 

The C version of AT91 works much, much better than it used to with the IRQ handling and sound buffer updates.   Many people impacted by the crashing glitch run the majority of SAM roms with JIT turned off just fine.    The only ROMs that actually require it seem to be TWD and Star Trek LE, they will sometimes lose "synch" with the serial RGB lights and start running in slow motion.   That issue might be fixable with some timing adjustments.     I don't think the performance of the C core is as much of an issue on modern systems (and if it was, they could go back to 32 bit).

 

Edited by DJRobX, 02 February 2020 - 12:50 AM.

[DJRobX]

 

 

Is it possible to have an option to place a "top plane" or "roof" on top of the visible walls for a ramp?

 

If this gets implemented, it would be good to have this "tunnel" shape collidable as well, for the use case given.   Being able to enclose ramps would also be amazing for helping with "ball flying off table" issues.   It's really tough to avoid the ball climbing a wall and going airborne if it goes up an incline, then around a corner.   Don't know how many times I've copied a ramp and placed it over top of itself ~60 points higher.    

[rothbauerw]

Here's a sample table with the ball falling through the primitive playfield.  I've also tested with a simple primitive object and the behavior seems to be the same.  I set the ball mass to 0.8 in the script. Just cradle the bHere's a sample table. I set the ball mass to 0.8 in the script. Just cradle the ball on a flipper. The positions of all the balls should be visible in a text box (x, y, z).

 

@toxie and @fuzzel

 

Let me know when you've pulled this down so I can remove the link.

 

[Link removed]

Edited by rothbauerw, 03 February 2020 - 02:24 PM.

[toxie]

avs?

[fuzzel]

ah for all of us who don't use LSD while playing pinball?

Seriously: a clear NO from my side.

Here's a sample table with the ball falling through the primitive playfield.  I've also tested with a simple primitive object and the behavior seems to be the same.  I set the ball mass to 0.8 in the script. Just cradle the bHere's a sample table. I set the ball mass to 0.8 in the script. Just cradle the ball on a flipper. The positions of all the balls should be visible in a text box (x, y, z).

 

@toxie and @fuzzel

 

Let me know when you've pulled this down so I can remove the link.

 

[Link removed]

Link is already gone...so I can only speculate: the playfield mesh handling in VPX is the same as with all other mesh primitives. So either it's the playfield mesh itself that has some problems with polygons or there is a general collision issue with all primitives.

[CARLOSGUIZZO]

ah for all of us who don't use LSD while playing pinball?

Seriously: a clear NO from my side.

Here's a sample table with the ball falling through the primitive playfield.  I've also tested with a simple primitive object and the behavior seems to be the same.  I set the ball mass to 0.8 in the script. Just cradle the bHere's a sample table. I set the ball mass to 0.8 in the script. Just cradle the ball on a flipper. The positions of all the balls should be visible in a text box (x, y, z).

 

@toxie and @fuzzel

 

Let me know when you've pulled this down so I can remove the link.

 

[Link removed]

Link is already gone...so I can only speculate: the playfield mesh handling in VPX is the same as with all other mesh primitives. So either it's the playfield mesh itself that has some problems with polygons or there is a general collision issue with all primitives.

[toxie]

Ah, that AVS.. I remember that from 15 years ago.. Or was it 25 already??

 

So you render psychedelic stuff to a texture and want to see that texture during pinball playing? WTF?!

Don't get me wrong.. I did code a lot of psychedelic demos back in the days, but this is just pure nonsense to support for a pinball engine..

Just dload one of the many light synths or some Llamasoft games and trip out in VR to that..

[Knorr]

I would like to have a option where I can load the table without textures. Just some minimal shading in white or something like that. Would make my life easier with the laptop. At the moment I simply delete all and reimport them back :/

[rothbauerw]

 

Here's a sample table with the ball falling through the primitive playfield.  I've also tested with a simple primitive object and the behavior seems to be the same.  I set the ball mass to 0.8 in the script. Just cradle the bHere's a sample table. I set the ball mass to 0.8 in the script. Just cradle the ball on a flipper. The positions of all the balls should be visible in a text box (x, y, z).

 

@toxie and @fuzzel

 

Let me know when you've pulled this down so I can remove the link.

 

[Link removed]

Link is already gone...so I can only speculate: the playfield mesh handling in VPX is the same as with all other mesh primitives. So either it's the playfield mesh itself that has some problems with polygons or there is a general collision issue with all primitives.

 

I tested with a basic primitive and the same behavior occurrs, so I think you're correct that it could be a general collision issue with all primitives.  I'll PM you the link.

[Schlabber34]

When i make the cutouts for the wire rollover targets i always have to place an invisible collideable wall at Z-0,1 to stop the ball from falling through the PF. The cutouts width is only about 20% of the ball diameter. It shouldn't fall through!

Is it possible that the collision detection in Z is only done with a point on the intersection of the outer skin (ball) and the balls Z axis? 

[wrd1972]

Are there currently in "working assumptions" that are being considered for the next rev?

[fuzzel]

Still working on the UI. But we're getting close Here is a screenshot how it looks like now. You can now select elements from the layer dialog by double-clicking on it and you can hide single elements by unchecking the checkbox next to the element name. If you check/uncheck the layer every element in that layer will be hidden/shown. You can rename a layer/element if you slowly double-click the entry. I want to add a filter textbox at the top of the dialog so you can enter some filter text and only matching items will be shown in the tree.

Attached Files

•  screenshot.jpg   99.78KB   12 downloads

[dark]

I feel for some models we aren't getting as much out of normals bump maps as we could be, in most applications that support normals bump maps there is usually a variable for amount, in 3dsmax it can be from -999 to +999 (while a realistically usable range is typically -100 to +100, sketchfab has a slider with no number indication but has a good range, UE4 has something similar and so on.  It's hard to say exactly, but I think VP has a bump strength of about ~45-60 in 3dsmax, but I usually find a strength around 85 is optimal for most of my models.

 

Would it be possible to add a normals bump strength variable? 0-100?, or even just pre-set strengths like, low-med-high?

[LynnInDenver]

Still working on the UI. But we're getting close Here is a screenshot how it looks like now. You can now select elements from the layer dialog by double-clicking on it and you can hide single elements by unchecking the checkbox next to the element name. If you check/uncheck the layer every element in that layer will be hidden/shown. You can rename a layer/element if you slowly double-click the entry. I want to add a filter textbox at the top of the dialog so you can enter some filter text and only matching items will be shown in the tree.

Oh... oh wow... I'm loving the idea of that layers implementation. And being able to toggle the visibility of individual elements is absolutely something that I'm sure I could find an immediate use for. Any chance you can also make a filter for element types in the tree, like being able to see just timers?

[Thalamus]

@LynnInDenver. Use element selector and pick all the timers. Now move them to the layer you want - done.

[toxie]

I would like to have a option where I can load the table without textures. Just some minimal shading in white or something like that. Would make my life easier with the laptop. At the moment I simply delete all and reimport them back :/

Is it due to the memory these are using on CPU and GPU? Or just in general the overhead of loading/pre-processing these?

When i make the cutouts for the wire rollover targets i always have to place an invisible collideable wall at Z-0,1 to stop the ball from falling through the PF. The cutouts width is only about 20% of the ball diameter. It shouldn't fall through!

Is it possible that the collision detection in Z is only done with a point on the intersection of the outer skin (ball) and the balls Z axis? 

Actually not, but the collision handling code is still not the most robust one, also due to many heuristics that were added over the years. My attempts at cleaning all of that up are still hidden behind a define, as it's also not perfect.  :/

 

Do you have a simple repro table for this, please?

Are there currently in "working assumptions" that are being considered for the next rev?

OGG and MP3 internal support, but still a bit rough on the edges   :/