1394 replies to this topic

[toxie]

I thought about simply using Embree http://embree.github.io (but maybe 1.1 instead of 2.0 as it is cleaner for our purpose), but the main problem is collecting all the triangles upfront for the ray tracer..

Ideas from your side on how to do this without messing up the code even more?

Edited by toxie, 28 October 2013 - 12:39 PM.

[fuzzel]

Hmm I don't know Embree is that a library you can use? It sounds very promising though, but I fear you have to change a lot in the code to collect all required information.

[toxie]

Embree is a pretty fast/stable ray tracer released to the public and relatively self-contained (at least in the 1.1 release).. I have actually written plenty of RT cores myself but not one that i could release as open source without getting my butt kicked.. :/

 

As for the code mess-up: I thought of kinda abusing all the things that you already did for the vertex buffers.. So everywhere where it's already possible to get a vertex buffer, one could also hook the ray tracer in to get the ready made triangles there.

Then getting ambient occlusion from that (or maybe even something fancier, given that the object colors are correct, cause textures i wouldn't want to touch for this yet) would be a simple shader to write in software.

[kiwi]

Thanks jimmyfingers, with RO disabled the frames are normal, even with many static objects.
 

The ramp not visible, maybe it's a compatibility problem between Vp915 and the revisions, the table is made with VP915.
If I replacement the ramp with his copy, the problem is solved.
 

Thanks and sorry if I made you waste your precious time.

 

Max

[jimmyfingers]

A bug has been introduced since the static primitive feature and when it is enabled it can cause odd colouring aspects on other objects (seemingly dynamic ones like drop walls and the plunger).  I'm attaching a screen shot which is from the same test table attached in my earlier post about the performance of .TopVisible disabled primitives (i.e. use that previous post / table to reproduce the issue).  You can see from the picture that the slingshot animation is now coloured instead of just white.  It also discoloured the plunger slightly and can be seen as well in the capture.

 

 Static Primitive Drop Wall Colour Bug Capture.png   474.73KB   9 downloads

[fuzzel]

i think this is fixed with rev 687.

[jimmyfingers]

I confirmed it wasn't working in the latest 688 before posting - sorry to have left out that detail but you can generally assume I've tested with the latest VP build if I don't mention a version.  You should be able to see for yourself with the primitive test table from the previous issue.

[jpsalas]

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

Thanks fuzzel Now it is time to take a look at this new options for the primitives

[fuzzel]

I confirmed it wasn't working in the latest 688 before posting - sorry to have left out that detail but you can generally assume I've tested with the latest VP build if I don't mention a version.  You should be able to see for yourself with the primitive test table from the previous issue.

Ok found and fixed it with rev 689.

[ICPjuggla]

Just wanted to jump in and say thank you for all the cool new stuff..

[jimmyfingers]

 

I confirmed it wasn't working in the latest 688 before posting - sorry to have left out that detail but you can generally assume I've tested with the latest VP build if I don't mention a version.  You should be able to see for yourself with the primitive test table from the previous issue.

Ok found and fixed it with rev 689.

 

It's awesome that you fixed and released the build in less time even than it would take for me to order a pizza  

[fuzzel]

[UltraPeepi]

This was repro'd with build 689.

 

 SphereMapProblem.png   216.63KB   11 downloads

 

Notice how the light always comes from the inside of the circle of models.  I should be able to rotate the model with the sphere mapped texture such that the light comes from a consistent direction.

 

This occurs whether I rotate using RotZ or ObjRotZ.

 

The two work arounds would be, never rotate a sphere mapped model (make sure the model is rotated such that when it is imported, it appear with the correct orientation).  OR, I believe I could apply a rotated sphere texture to match the rotation of the object (I didn't actually try this).

 

Thanks again for adding this feature.

 

[fuzzel]

The sphere mapping is actually a hack. I take the vertex normal as texture coordinates because the normals point away from the object. The origin of a sphere map is always the middle of the texture and the mapping result is that the middle of that texture is facing to the viewer/camera. Maybe that helps a bit in understanding why it behaves like that.

[UltraPeepi]

OK.  That makes perfect sense.  Can you try one more "hack" on top of that?  Can you look at the RotZ and rotate the sphere map before applying it?  I think that should do it.  If you want, I can create several rotated textures and test to see if that produces the correct result - before you commit to coding it up.

[UltraPeepi]

Nevermind.  Don't change this on my account. 

 

 SphereMapProblem_applied_rotated_spheres.png   221.25KB   9 downloads

 

Here I created a series of rotated spheres and applied a different texture to each based on RotZ.  It's not perfect, but it does give a better mapping than before.

 

This is easy to account for in table code.  I should be able to create a collection for "sphere mapped objects".  Then, I can iterate through them and alter their texture based on RotZ.  In fact, I can probably get by with 8 textures, round RotZ to the nearest 45, and apply the nearest texture.  For objects that get rotated a run-time, I just need to apply the rotated texture when I rotate the object.

 

Is TableInit going to be called at a time when I can do this for pre-rendered primitives?  If not, I can apply it at design time.

Edited by UltraPeepi, 29 October 2013 - 07:46 PM.

[bent98]

We need a good soccer ball in World Cup Soccer.

[fuzzel]

Ok I found a bug with the sphere mapping texture coordinate calculation. With rev 693 the orientation of the sphere map ist correct now, means that the middle of a spheremap is always facing towards the camera/viewer.

[UltraPeepi]

Fix confirmed.

 

Fuzzel, you are like a genie.  Can I get sphere mapping? Bam, sphere mapping.  Can I get an issue fixed?  Bam, issue resolved.

 

For my third wish, can I get three more wishes?

[daveboy6]

Dont know if this realy belongs in this conversation but... It would be great if you could rotate a wall by it's Z axis in VP. This would enable you to create the coneshape standoffs like in the older Williams machines, without resorting to making a bunch of flat walls of varying sizes in a stack to get the illusion of a cone shape. This would also allow you to put a texture on the wall easily. It would also allow you to make roundish shaped rubbers without using the same flat pancake stack trick.