Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

Ostatnie posty - Strona 738

  Forum

readyforanything
Dołączył: Apr 2011
5037 post(y/ów)
TheEmu
Dołączył: Jul 2012
7424 post(y/ów)

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Wszystko o iStripper
July 30, 2020, 5087 odpowiedzi
It looks like it's not sorting the depth according to the camera view but is doing it according to the sprite order in the scn as one wall is perfectly fine while 2 have the error.

The elements in a scene are rendered as if

1) each is drawn on its own layer of transparent film
2) these layers are then stacked in the order in which they appear in the .scn file

the first step takes the distance from the camera into account. The second does not, If you don't account for this in a.scn file the results can, and often do, look very odd - especially if you are moving things about in a scene by animating their positions or they are rotated about X or Y. If complex movement is involved then it is often necessary to duplicate elements and animate their opacities such that only the right one is visible at any time.

As an aside, I think the GLSL fragment shader language provides a way to change the Z buffer value of a pixel which could form the basis of correcting the ordering so that it is based on position in 3D space, but I have not investigated it yet. It is on a long list of things I hope look at.

The finish of this really surprises me every day (I never imagined that the software will endure something so complex). Visually playing with perspectives and other gadgets, it makes the software very entertaining and with good hardware it is really a delight.

I also find it surprising just what can be accomplished using just the functionality provided by the .scn files even without resorting to either fragment shaders (the .fsh fils) or vertex shaders (there are a few scenes around that use these to distort the geometry).

I first got hooked by scenes when I created my "experiments with carousels" which I treated a kind of puzzle to see how far I could push the capabilities of the .scn files - then I discovered the fun of shaders.

However, it has to be admitted that doing anything complicated involves a lot of often very tedious work. I have quite a few ideas that could lessen that - for example the use of macros I mentioned a few posts back, some built in arithmetic capability and the ability to direcly specify the sorting order for sprites rather than having it simply be the order in which they are defined. One day I may get those ideas into a coherent form and post them here.