I’m building a GUI for live sets and i have to face different problems…The first one is about antialiasing…I’m feeding a post-processing shader with a DX9texture (so i can’t use the inspektor’s antialiasing because of the depthbuffer) and i don’t know how to set the resolution of the original renderer, the DX9 texture and then the final output (working in spanmode) to get a clean antialiased picture(i tried some tweaking but can’t get a good result)…
The second problem is the postprocessing subpatch itself…I can control for exemple the enum of the techniques but when switching to fullscreen the enum doesn’t work anymore (then it outputs :(nil))…The postprocess subpatch is a part of a bigger one which include the create node system and a set depthbuffer patch (with set patch, etc.)…maybe it has to do with it…
got the same problem with enum of the techniques
instead of different techniques, try using different passes, it should work when going fullscreen
problem: as soon as you go via dx9texture you’ll lose antialiasing. everything rendered to a dx9texture is aliased.
still you can set the resolution of a renderer or of any dx9texture (even independent of the renderer it is connected to) manually via the inspektor:
- renderers have backbufferwidth/height pins. if they are 0/0 the backbuffer adapts to the windowsize, which is the default. note manual backbuffers only work for windowed renderers!
- dx9textures have width/height pins. if they are 0/0 its size adapts to the backbuffer of the renderer it is connected to, which is the default.
concerning the second problem…
do you have a 3rd monitor on which you have the patch and see that the technique enum is nil? or how did you find out?
anyway this seems to be a bad bug.
Tx Joreg this is clear!!
So, is setting double size would work?
about the enum bug…i can figure it out by clicking on the interface and also when i switch to window mode again…
jo, doublesizing and scaling down should improve quality a little bit.
bad enum. we’ll probably have to dive into that…
That enum is what we’ve been reporting for a long time!
Using passes is a good work around though
Using multiple passes instead of multiple techniques works fine…but the technique enum still displays nil when fullscreened…hoppefully it doesn’t seems to confuse the shader because of the only one technique by default…so let see what the futur brings…
Another fullscreen bug…using keyboard(systemglobal
) and =(string)
set to respond to space …working in windowed mode but not anymore in fullscreen…(if i take a look at the keyboard node the ALT is stuck in the output…)so i switched to =(value) with getting the spacebar keycode…now it works!
And by the way do i need a mainloop in my interface, and how to set it??
desaxis you are using beta13 or 13.1, right? or still 12? because we fixed one of the enum-problems with effects for beta13…but probably not all.
I’ve definatly seen the nil enum in beta 13.1 although mostly I’ve moved to passes now so cant say how often
Ok, i was using beta 12…and i just tried different techniques enum with beta 13.1 and it seems to work now (for the postprocessing patch,i will try for others soon)…and performances are a little bit higher i guess…
ah, there we have it… why use beta12 when 13.1 is much fresher?
c’mon cat don’t do this to us. are you sure you’ve seen them? please desaxis tell us it is all good now.
I made some more tests with shader techniques enum inside patches running throw the interface and guess what?..everything’s fine…no bug at all :D
And about beta’s switching i have to clean up a bit my module mess…to get everything running under 13!!
(cat, your turn…)
i’m using set patch to enable (or not) the depth buffer but doin this result on a little flickering when switching patches…i can see the depth buffer working (or not) on the first frame…so my first idea was to use some fade2black between switches but maybe there is a trick to make set patch work in an efficient way…and i also wanted to know if the subpatche’s location of the main loop is important and again how to set it?
i am afraid switching the depthbuffer will always cause a little flicker. fading to black should be your best option.
“the subpatche’s location of the main loop is important”
not sure what you mean with that. you can place the mainloopnode anywhere. just make sure to only have one instance of the node. so you best put it in the root-patch.
how to set is?
however it suits for you best. which settings do you not understand? checked its helpfile?
i haven’t seen the mainloop help patch…but it says that filtered is default…but in reality its raw…Do i need to decrease the foreground framerate to 60 for exemple?
Anyways its clear now!!!
I’ve noticed some strange bugs using the mainloop node…Even if i save some values, when restarting my patch the loaded settings are always the same : 45 for the 2 max values and setted to raw…and sometimes (now i’m using only beta13) the asyncronous pin doesn’t appear…strange!
And the second thing:
when using create node u always need to save the patch with ID=O at the end in order to get everythings’ loading well the next time…So i tried getnode ID from Catweasel but i got a really big loading time…maybe that’s because i’m using twice get and set patch (one for depthbuffer and one for ID)…so do i need to concatenate them in only one patch and then get only one set and get patch for better perfs…
if your mainloop always loads with the same settings you probably have a second mainloop-node hidden in any of your (sub)patches.
note that you can only use one instance of this node. other instances may overwrite its inputs.