1488 replies to this topic

[cyberpez]

Thanks for the hint Joe..  the command .enabled instead of .collidable worked!!  The flipper is still there and collidable, but I think I can work around that.

[gtxjoe]

I assume you have seen the 3 KIng Kong restoration albums here
http://christopherhu...lery/albums.php

Edited by gtxjoe, 13 June 2019 - 11:18 PM.

[cyberpez]

Thanks I had seen the finished product... But had only noticed the in progress ones a couple days ago.

[djredick]

Just grabbed the VPX_6_beta_rev3723 package, and for some odd reason, I cannot rename VPinballX!

 

I get the message below.

 

 

I am trying to rename it to VPinballX_v10.6r3723.  I have added folder exceptions to both Avast! and Malwarebytes, and even taken ownership of the file, to no avail.

 

Is there something internal to the file that is preventing me from renaming it?

[luvthatapex]

I had a similar problem where everytime I launched vpinballx release 3722 or 3723 user access manager would pop up in windows 7 and ask me for permission to run the application.

It didn't matter if I ran it as admin or unblocked the .exe

something is different the way the vpinball.exe was built the last 2 versions.

 

Just grabbed the VPX_6_beta_rev3723 package, and for some odd reason, I cannot rename VPinballX!

 

I get the message below.

 

 

I am trying to rename it to VPinballX_v10.6r3723.  I have added folder exceptions to both Avast! and Malwarebytes, and even taken ownership of the file, to no avail.

 

Is there something internal to the file that is preventing me from renaming it?

Edited by luvthatapex, 14 June 2019 - 03:46 PM.

[djredick]

 

I had a similar problem where everytime I launched vpinballx release 3722 or 3723 user access manager would pop up in windows 7 and ask me for permission to run the application.

It didn't matter if I ran it as admin or unblocked the .exe

something is different the way the vpinball.exe was built the last 2 versions.

 

Something that was weird with this one also.

 

I tried using the "Reset to Defaults" option under the video/editor options, and it not only closed VPX, but also deleted it from the folder!

 

Don't know if my anti-virus kicked in and quarantined it as I didn't get any notices to that effect.  I used that option a few builds prior without issue.

[Caligula_]

Asking Christoph would be the easy part, as i know him pretty well. We could also go for a interop solution and only trace rays via vulkan, and do the rest via GL. At the moment this seems to be the fastest solution to drive RT cores anyway (i.e. not much shading done via closest/any hit programs, but doing that in separate progs similar to deferred rendering).

 

I'm personally against using a game engine, as the main fun i have contributing to VPX is that i have full control over everything, which also can pay off, one prominent example being the split into static and dynamic rendering that we use nowadays. Similar things could be done when going full dynamic lighting as most of the table is still static geometry all the time, so the tricks to get high quality lighting can vary a lot from games.

Plus one not only gets all the goods but also all the bads from using such a huge thingie.

Maybe OpenGL will get ray-tracing extensions, it's not impossible that khronos group is working on that, maybe ATI will release RT hardware and compete with Nvidia bringing prices down making it a more common thing and not just for high-end rigs, I'm interested to see where ATI's new architecture will be positioned in terms of ray-tracing, I mean ATI chips are in both PS5 and Xbox Scarlett and those will have Ray-tracing support so competition is around the corner.

 

To all my knowledge there is no support planned for GL at the moment. Also Xbox will obviously be DX based again, and PS5 may use something Sony exclusive again i'd guess (similar to PS4).

 

Using an engine has advantages and disadavantages. Downside is definitive the licensing issue (which disqualifies any commercial engine like Unity or Unreal), the missing control over features and a really hight (one-time) effort for porting to an engine. And of course the missed fun of coding. But when I look at features like DX12 / Vulkan support, using materials instead of writing shaders, realtime lightning, refraction or raytracing - implementing and maintaining them  would also consume a lot of time that could be used for other stuff. I'm fine with both ways, but I wanted to explain my point of view.

[Thalamus]

I just wanted to say that I would be scared if you picked a new direction where the devs don't enjoy the work they do.

[Caligula_]

I just wanted to say that I would be scared if you picked a new direction where the devs don't enjoy the work they do.

 

I didn't want to be offensive (I'm sorry if I sounded that way). I just wanted to state my opinion. I really appreciate what toxie and fuzzel (and all other developers) are doing voluntary for all of us.

[Knorr]

 

I have to jump in here. 

 

 

A week ago or so i talked to CK that i build my next table in mm/metric system in hope to get better physics with the ball. Until now i always build in scale 1:1.85.

 

 

I think this hole idea to convert vpu to mm goes in the wrong direction.

 

So just for a reminder... we still don´t know exactly what a vp unit is... The 0.54mm = 1vpu is somehow old, back in time (VP8) where the ball standard defintion was 50 and the ball not 3d.

 

My idea was to simply use a metric system for a table without keep care of vp units. So the ball diameter is 27mm (or 1 1/16inch) instead of 50 and look how it does affect the hole table.

 

On the other hand cinema 4d takes the measurements how they are already in vp, so lets say a wall is 60 units high in vp >>> C4d 60mm (without changing something in the import). Maybe some blender/maya or whatever user can take a look at it too.

 

 

I found the old thread where noah brouhgt that up...

 

https://www.vpforums...?showtopic=2762

 

 

EDIT: When i build in mm the table gets smaller, i dont know if this affects shading/render stuff...

 

For Blender it's the same: 100 vpu are 100mm or 79.33'. So if you would use it 1:1 it means that a length of a playfield of 2162 vpu would be 2.162 meters or 180.17'

 

 

No, i built 1:1,85 which means the 27mm ball is in vp a 49,95mm ball. Honestly i always used 0,54 for calculating because it gave me nicer numbers... So 27mm / 0,54 =50.

 

Now i want to build 1:1. This means 27mm in real life are 27vpu.

[fuzzel]

rev3738 is up:

 

- change Position() of the plunger element to return a float instead of an integer

- code cleanup

[bord]

Maybe not for 10.6 since I know you guys are wrapping things up, but is it possible to make a kicker only collidable from the top or bottom? For example, I want a fall through kicker to work only one on the way down and not grab the ball on the way back up.

[BorgDog]

 

 

feature request/change:

 

On hit targets, round, rectangle, slim the bracket built into the objects sticks above the target face.  for many new machines that is basically correct, but for the older machines I primarily build the bracket does not stick up above the target face, and I actually have to put the target lower than real life to have the bracket not stick through the plastics.  

 

Ideally would it be possible to decouple the object so that the bracket can be height adjustable separately from the target face? that way it could work for whatever case and the table builder could adjust to their liking?

 

Along with that currently the bracket is animated along with the target face when hit, when it really shouldn't be.  Most tables you can't really see that effect, but on ones where it can be seen it looks rather odd and once seen it can't be unseen.  along with decoupling to adjust the height separately could you not animate the bracket as well?

 

I personally would be OK with removing the bracket from the built in targets if that what it takes to fix these things, but of course I realize it would likely 'break' a lot of tables, well not really break, just no longer have a bracket.

 

 

I wanted to bring this back forward into the new beta thread.  And maybe add in some enhanced animation like 3rdaxis is doing on his firepower build to have some bounce in the target.  If bounce is added I would like it to have a damping variable so that we could control how much bounce occurs.

 

Thanks guys!

 

 

bump this back up.  can we get some target updates please.  Thanks.

I don't remember if I asked this before or just thought about asking it (yes I'm getting old , but would it be possible to have the Import Mesh on primitive objects work so that if I select 10 objects I just have to tell it once which primitive to use instead of 10 times?  I seem to find myself doing this a lot making tables and it would be a great time saver.

 

Thanks for all your work guys.

 

bump this up as well.  just did another swap of 50 or so posts on a table would be nice to have to just tell it once what primitive to use.

 

Thanks.

[toxie]

 

add abscissa and ordinates for timers ( to align the timers cleanly and quickly).

and add DLSS .

 

Possible ?

 

could you elaborate on the timers? i don't get what you want..

DLSS: At the moment DLSS is trained for each title separately, so there is no general support yet for all kinds of games.

[fuzzel]

rev3743 is up:

 

- add object space-normal mapping support to primitive (our implementation matches the object space, +X +Y +Z, export/baking settings in Blender)
  Object space-normal maps are commonly used if one reduces polygon counts of a complex model. The lost geometric details are then added back via a normal map
 

[flupper1]

I provided fuzzel and toxie with the test primitive to work on the new object space normal map implementation, which is my Totan lamp. I never could get the normal map of the lamp to look right in VPX, even though it worked in Blender. After some google searching I stumbled onto this page:

http://wiki.polycoun...chnical_Details

 

Which explains that there are two (usable) types of normal maps:

- tangent space

- object space

If I understand correctly, tangent space normal maps work by bending the existing normal of the primitive based on the normal map. That has several advantages, but it seems one big disadvantage: it is very dependent on the way the primitive normals are calculated (usually software/game engine specific). Maybe this is why I could not get a tangent space normal map from blender to work correctly in VPX.

Object space normal maps do not have this disadvantage, since they replace the primitive normals by the normals in the normal map. They also have some disadvantages, but less troublesome in VPX.

 

So this is how it looks like now in VPX:

 

On the right you see the relative low poly model (5k triangles) of the lamp without a texture and without a normal map. You can see it has no detail on the top flat face, the "ear" of the lamp nor the bumps around the top dome, nor the bottom. On the left it is the same but with a normal map. Middle top is a screenshot from blender what it should look like. Mission accomplished I would say! The material is on the top left, note the shininess of 10 which gives the high gloss (i think 2 is also enough for this effect btw).

 

This is the same but with a non-metal material:

 

If you use a shininess of 1 for the metal material, it looks like this:

 

With a texture and a different environment image you get the more weathered look of the lamp:

 

The normal map itself looks like this:

(there are still some errors I have to fix in the normal map, you can spot them for instance on the bottom screw)

[dark]

"Normal maps  can be made in either of two basic flavors: tangent-space or object-space. World-space is basically the same as object-space, except it requires the model to remain in its original orientation, neither rotating nor deforming, so it's almost never used." 

 

That rainbow colored normals map indicates 'World-space',  why not just generate a 'object-space' one instead?  If you have both low poly and high poly versions of the model still I can help with this if you need.

Edited by dark, 30 June 2019 - 02:23 PM.

[flupper1]

@dark: this normal map is in object-space and works fine in VPX, lamp can rotate and all. Tangent space are in blue tones, object space (and I think world space) are in rainbow colors. Only drawback for VPX of object space maps, is that character deformation might not work properly, but that is only with an animated primitive (multiple frames of primitives). 

[dark]

The deformation you are referring to is mesh deformation from skin modifier or something similar, like a character rig that can bend it's arms/legs.

Yes I meant to say Tangent space not object-space.  I've never had any issues with tangent space (blueish) normal maps with moving or animated prims in VP.

Glad to hear it's working for you.

[wrd1972]

I think I found a "video options" bug. Its to do with manually defining "ball aspect ratio". he ball looks very "squashed", compared to an earlier version.

 

Here is what the ball looks like with rev. 3696

Kind of seems that the ball can not be manually re-sized at all. It never changes with setting revisions.

 

 

Here is what the ball looks like with rev. 3738

Works great here.

 

Defining these settings is my solution to "egg-ball". Am I maybe missing something, or is it areal bug. If it is a glitch, can this please be fixed before final release?

 

Thanks.

Edited by wrd1972, 30 June 2019 - 04:03 PM.