@EverthangForever

In the edit to your previous post you said "I'm wondering if the Complex Functions shader is having difficulty rendering some of the more concentrated iterations."

I assume that you are talking about the result of using the Complex Function shader when using it to distort an image. If so then what you are seeing as "jaggies" are probably due to the finite pixel sizes involved. In principle this could be overcome by using a much higher resolution for the original image - but that is not practical. The problem is exactly that which used to be seen when rescaling any digital image or font, but which is much less often seen nowadays because anti-aliasing techniques are used. It would be a good idea if anti-aliasing were built into the Complex Functions shader, but I do not have it as a high priority on my "to do" list.

Update: What happens when you use a "texture" is that when the shader is determining the colour to use for a particular pixel in the image being generated it determines what point in the texture image corresponds to the pixel in the final image and uses its colour. In general this will not correspond exactly to a pixel in the texture and the actual colour used will be some sort of average over the nearest pixels in the texture. This is done by the GLSL function texture2D.

This works quite well if the texture image is smaller than the image being generated (though a simple minded averaging can lead to a blocky final image) but has problems when the texture image is much larger than the image being generated. In this case two neighbouring pixels in the image being generated may correspond to widely separated pixels in the texture. Because they are widely separated any averaging over neighbouring texture pixels does not help because the two points in the texture are too far away from each other to be neighours.

Strange as it may seem you might actualy get a more smoothly coloured result by using a smaller texture, but of course you then ***** from the lower resolution in those parts of the final image that are not affected by the relative scaling of the generated image and the texture. As I mentioned above probably the best thing to do is to apply an anti-aliasing step to the final image.

Things are, of course, rather more complicated than what I have described, but it gives the gist of the problem.

@TheEmu
Thanks for that clarification. '..probably the best thing to do is to apply an anti-aliasing step to the final image ' ..sounds like a practical solution to the problem. I will experiment with different sized images & revisit @Lezardo's anti-alias shader to see if that can be worked around & applied somehow in there also, although the 'jaggies' probably requires an anti-alias hard code change somewhere in the shader someday, to properly optimise the result as you say. The Complex functions shader incl. progressive steps is really awesome as a concept.

With respect to the Unknown - e#22678.2 - Modified.fsh ...& recent uniforms, we appear to have been engulfed with the fiery background now (Reds/yellows) swamping the torus. I tried a barrage of tweaks to try to send it back Z-wise in 3D camera however only managed to change overall the colour (line 191) not the background's pervasiveness/distance from the camera, eg (above pic):
191 // was color = hsv(d, 1.0, 1.0)*mind*45.0; // Background
192 color = hsv(d, 0.3, 1.0)*mind*45.0; // Background
193 return color;
Edit: Ooh Ahh..just saw Melena Tara spinning back to dressed mode on fullscreen..I thought a few of these transitions slipped through..don't mind at all .. as long as the hanging ones stay away 😉 lol.

@EverthangForever

Coincidently I have just uploaded a set of updated Transmat scenes in which the fire tunnel is less overwhelming. The tweak to do this is to reduce its opacity via the scene file, either via the Tunnel A shader's Tanslucency uniform, or via the opacity: or opacity animation when using the framebuffer.

@TheEmu, wow that was quick with the shares updates..THANKS a lot.
Well that does it..I have to get PaintShopPro now...
I've presume any shaders of same name are backwardly compatible and set extract to replace all
Now peeps have to remember to check updates of shaders (if any) are transferred to their working directories.
Wonderful work @TheEmu..outstanding !!❤️

@EverthangForever - Yes everything is backwardly compatible.

@TheEmu, Oh thats a relief..sometimes the prospect of changing details/paths in zillions of scene files can be a daunting one. Dankeschön

Edit: In the new Club based Transmats I like the use of the time coordinates shader alternating with various clones of the dancer. Especially the way the tunnels behave & models move. The timing of the way you've made all opacities change is very immersive indeed. The progressive tunnel of flowers Indian Archway and infinite Perlin noise have similar immersive effect, very 3D and adaptable..

going way off topic here...
but I thought this was funny...

top picture is an Emu
bottom Picture is Albert Einstein

remarkable resemblance?

:-))))))

E=mu (if u=c^2)
:-)

Thanks for all 'em u do :-)

Who ever said geniuses have no sense of humour? Roflmfao! :DDDDDD

@EverthangForever

I had already come across of the picture you posted of "the emu in the sky" and the rock art depicting it. Thanks for posting it. As you might expect there are some myths about it, including at least one explaining how an emu got into the sky in the first place. I had even briefly considered using it as my avatar.

@TheEmu,
The Emu egg is seen by Australian indiginous artists as important in that to collect them requires the skill of a hunter and those who aquired them centuries ago demonstrated a profound knowledge of nature. In the latter century & particularly recently the eggs are protected and because the carving needs to be done to critical depths to get the exact colors their art is highly valued. It has grown to symbolize a unique connection humans have had with the land & animals from the earliest times. A darn good avatar full of allegory, ..spot on..if you ask me.😉

Useful discussion on scene model entry reversals at thread:
Fullscreen: 'inout' entry from the left, and asymmetric card mirror

http://www.virtuagirl.com/forumPost.php?foId=3&ftId=30784&gotolastpage=1#post475984

Tutto su iStripper / Fullscreen: 'inout' entry from the left, and asymmetric card mirrori

I recently noticed that my fullscreen example of a clip which allows 'inout' cannot be caused to enter from the left because scale: -1, 1, 1 must be used in case a card is asymmetric (e.g. Alice Saint...

reciprocally linked here... Nice explanation btw @hombre ;-)

Edit: Pic from @Rex, ages ago..Totem can be "cheeky charlies" at times..There was a thread long time back where someone did some forensics on the hanging picture to see if THIS also is in fact a mirrored image, but I couldn't find it. The lettering on the white drum looks left to right, so I guess it is the real view ;-)
I've always thought Desktop views are randomly flipped left-right or right-left periodically for variety purposes.

@ET: Remember a good while ago when we could choose which side the girls came onto our desktops? That's long gone of course :/

Without the Paris studio images (and this particular one doesn't really show it very well), I know for an absolute fact that ALL cards are filmed as entering from the right. Certainly the Paris studio cards to date, at least.

No idea about the new Vegas cards as yet as I haven't checked this issue with them. If they've been switched, then this could get complicated!

Anyone reading this can easily check this out. Go thru your collection till you see a girl's card with some writing on it. (Tee-shirt, tattoo or whatever). Open it on your desktop. Almost all of the time, the writing will be reversed and the girl will enter from the left. If the writing is correct, then she has entered from the right.

Now, if you've used Fullscreen and have seen the same girl or others with the writing correctly displayed in a given scene, I'll also pretty much guarantee you that there is one of two lines of code in the 'clipSprite' chunk of code for that scene.

For spacial positioning in 3 dimensions, we have X = horizontal. Y = vertical and Z = depth or distance from viewer/camera.

scale: -1, 1, 1 (The more common one)
This also says, X = Minus 1, (Flipped) , Y= 1, (As is) and Z = 1 (As is).

OR

rot: 0, 180, 0

The first one mirrors the X axis, (flips it horizontally). The second does the same thing but in a different way. It ROTATES the image around the vertical Y axis thru 180 degrees. ( Half a circle. You could set this number at 90 degrees and you'll see one extremely skinny girl!

@Hombre Sin Sombra

Based on a huge sample (of one card!!!) this appears to be a fullscreen software thing not a Paris vs Vegas studio problem. The only 3K US card I can think of that has text on it is a Desk Babes card of Alexa Nova. She has a very distinctive tattoo across her stomach. This displays correctly in fullscreen scenes that use negative scaling to ***** the clip.

While we are talking about positioning of models,.. I think its worth the camera Team to note that the latest Sapphira A card -'Outright Sexy'~ looks like it tends to play the model 250 or more pixels to the left of stage center x =0. This is probably why some deep leg clips in this card extend outside of my reflections mask range in the Fractal Garden 010C scene. Team mentioned recently how difficult it is to guarantee that every model will keep to center stage.. In the pic shown above you can see I have corrected my own PC's clipsprite pos: settings temporarily as code below to suit this card, however because we never have the camera shoot panning to follow the model, maybe some of this cards clips could have their internal posx reference adjusted one day by Totem for updates.

// model reflection
clipSprite {
pos: 250, -81, -720

@No.6: Thanks for that, buddy. Saves a lot of headaches for scene makers. Totem must be on the ball with this stuff ;)

@ET: For a lot of scenes, I doubt this would be a problem. But you're right, some of our scenes need the models to be placed precisely or the girls are going to be floating in thin air with their 'ride' off to one side. Generally this would be ok for most girls' clips but for the odd one that is recorded off-centre, it would be *****. Correcting for just that one model would then throw out all the 'normal' ones.

I agree. If Totem can correct these off-centre clips then that's great. I'm not sure if they'd be willing to do the work tho, just to please us fans of scene making :/

We have to bear in mind also that very few girls are static in the centre, even in sitting clips. Our scenes can only do so much to make the images look relatively realistic. Then the girls move off to one side and throw all our carefully calculated positioning way out of whack!

So, if Totem can do these repair jobs, wonderful! But I'm not going to let it bother me if they can't. I realise we are in a minority here and those of us that know how to do it can always make a copy of a scene and alter it for just one favouite clip so that it plays as we want it to:) As you did! ;)

OK @All

Just to prove there is an exception to every rule - MS (Oh God her nipples are amazing) Lynna Flying First Class.

The original video on this appears to be FUBAR'd and is reversed in the original clips. The SEX necklace appears the wrong way round and the badge is over her right breast. If you look at the photos for the session the SEX necklace is the right way round and the badge appears over her left breast. Consequently when the image is flipped in Fullscreen it is still the wrong way round.

TBH I must be really sad in the sense that I can tear my eyes away from her fantastic body (and did I mention amazing nipples) to actually notice this. :-)

Well No.6 hey not be so sad...maybe is because you can't be No.9 ...because 7 ate 9 😉

Hahaha! No.9 was definitely one of the hottest babes on TV :D

@No.6: You're right of course about Ms (Bullet Nips) Lynna. I think it was still recorded as all of the cards were but somebody screwed up in post production :/

Damn! Cant tear my eyes away from No.9. What a body! :D

Jeri Ryan as 7of9 was Hot..
she also did some very sexy photo shoots..
Maybe Totem should approach her..😛

In our dreams, Beastman! I forgot her proper name as I haven't watched Star Trek for about 16 years. 7 of 9 of the Borg. Wonder what the other 8 looked like ;)

Edit: A couple more hot pics of Ms. Ryan. The last one is how she looked last year. She's now 47 years old and still damned hot! :D

Thanks guys - the Jimi Hendrix song "If 6 was 9" is now running through my head. The consequences of that beggar belief. Either I would be less beautiful with smaller tits :-)))) or she would be so fat and ugly even the BORG would reject her.

@EverthangForever

Don't know, at the moment, what you did with @TheEmu's version of the Unknown #e226782.2shader but your recent Full Screens scenes all work quite well on my graphics card.

I have a number of shaders that I keep meaning to upload (but some people keep uploading stuff and I just don't seem to get round to sorting my stuff out :-)) - that and the fact I keep playing with them :-).

There are a few that have high value iterative functions to produce fine detail and some of them consequently stutter on my graphics card. This shader, in its original form, is one of them. My work around was to reduce the number of iterations in the loop which results in a loss of detail but lets the shader run without stuttering. It appears that your changes in the "formula" reduce the detail enough for the shader to work (on my graphics card) without actually reducing the number of iterations. Thanks - I shall now have closer look at this and see if I can adjust the formula values to produce the same effect without reducing the iterations.

@Number6
Well thats interesting, I had set the scene code's iteration uniform at

• uniform: maxIter, int, 25

instead of the default 70, to take into account less powerful graphics cards...so check that again.
However doing this * makes it run at breakneck speed on my system, and reduces a lot of the side detail.
In fact it looks damn dangerous for the model imho at that speed :-(
At home I run this at higher maxIter like 64 and hence its much mellower flight speed and includes more side detail. (viz above pic)
The background color using less yellow/green at line 192 in the shader, was really just an accident of attempting to reduce the bright garishness of the pervasive background caused by maxiimum iterations 25. It might well be a factor in the iteration processing because there was so much yellow before. Hope its a useful accident..so many can be ;-)

Edit: @Lmfao..don't encourage @Wyldanimal et al..they're bound to have a BORG reject pic somewhere 😛

@EverthangForever

That explains it then. I haven't had chance to look at your scene and shader files yet. I have iterations set to 23 in mine. It will go higher (up to about 40 I think) but I liked the lower detail better. I thought it may be the way you had altered the formulas for the background that had caused the changes.

@Number6
Sure. There has to be an optimum of settings for the shader and maxIter's ie: between the shader color values and uniform iterations allowed. Everyone will want more or less yellow in the torus also..just about every other value setting i played with in the shader affected iterations (detail of render) somehow visably. Yes i rather like the pale green & mauve spacey translucent looking background with this sans yellow. It doesn't distract too much from the model.

@TheEmu,
thanks lots for the bug-fix in Tunnel A shader and especially the new Function id panel for complex functions.
I'm hoping it will be possible one day to adapt such a panel to monitoring a currently playing SCN file's details (even if could just show the current SCN file name's ending characters) while a name-tree is playing in fullscreen, . In Milkdrop2 we always had ready access to fps, filename playing, even editing etc. without having to leave fullscreen. I really miss that !

I'm presently running around 30 copies of SCNs in their own name-tree group for GlslSandbox - Unknown - e#22678.2.fsh, all with different name endings corresponding to the FuncA,FuncB & FuncC uniform settings & it would be magic to have the option to see them and their MaxIter settings 'live' during fullscreen, so to speak.

@EverthangForever

I fully agree that it would be nice if it was possible to request, e.g. by a keypress, that at least the .scn filename is displayed when a fullscreen scene is playing and to then optionaly ask for more detailed information such as the names of the currently active clips and texture files and even the values of any uniforms that have been defined in the .scn file. Even better would be some way to tweak the values of the uniforms. These are among the list of the things that I want to think about before making any suggestions to Totem for future improvements

With respect to GlslSandbox - Unknown - e#22678.2.fsh, it should be a simple matter to incorporate a data panel for the uniforms you are interrested in as long as they are all integers. I do not have time to look at it just now but you ought to be able to manage it yourself. One of the things I want to look at over the weekend is to add the ability to display floating point values and then to package it up as something that can be inserted into any fragment shader, mainly for debugging but also, as is the case with the Complex Functions shader, to display information that is of use to the ordinary user.

@TheEmu

Thanks for the recent updates. I am now busily updating my scene files to incorporate the new uniforms.

Some time back you were muttering about the possibilty of randomisng the function changes instead of having them sequential. Did you manage to get anywhere with that?

I was thinking that if you could incorporate that along with the randomisation of new function modifications the combinations would be almost limitless. Virtually an infinitely changing pattern in the shader.