seems you haven’t found the
alt+rightclick = reset
shortcut yet. like this you can reset individual pins to their default values or when applied to a node reset all of a nodes pins. also mentioned here: the user interface in detail#changing values in the patch
of course it is frustrating that they didn’t yet manage to visually decorate pins that are not set to their default. jeeez devvvvs, what are you doing all day?!
and about pins keeping their data after being disconnected:
thats even more unintuitive once you understand that with all primitive datatypes (value, string, color, enum) the behavior is as you noticed, but with all others (mesh, texture, transform, …) it is as you expected.
we kind of learned to like it that way…for now at least…
Well, initially I found difficult to manage this behaviour of pins, but I guess was just a state of mind… I mean just a way of thinking.
Anyways, as long as I started to patch something more complicated, it helped me a lot to keep patch clean, avoiding spreading nodes all over the patch.
More, if I can suggest something, probably you won’t need an XY res of 30 for such a large number of objects: I guess you could reduce res proportionally to the quantity of objects, for example.
In the attached file I’ve put a spread of 1024 spheres, XY res = 30 and it runs at least at 30fps on an athlon 64X2 Duo, geforce9600 gt: rather poor, I know. But goin’ smoothly (yes, the result is ugly as death, but helpful, I hope).
Ciao.
PS: When you work with 3d objs enable ZBuffer to enjoy “depth”.
+1 oh yes, some feedback on pins which are not set to default anymore would be cool…it would make teaching vvvv a lot easier since this is the most common error my students make. like “i dont see my quad anymore, vvvv is broken”
Always check Herr Inspektor, whatever you do in vvvv, at least until you get really experienced. And learn also what different shades of gray of pins mean in the Ispektor -is it linked or not? That’s the question. Is it better to see in the Inspektor if a pin has spreads and how much, or in ye patch? The devvvvs will tell. I vote for one more shade of gray in the Inspektor.
@poof
I see your patch, it was kinda hanging and slow but i wondered why just to handle 2 simple nodes. I created another patch myself with similar properties you had, it was lite and fast as natural, there was no lag like in your patch. I have experienced such things before but worked perfect when i simply copy all the nodes and paste in new patch.
I don’t know V4 so much to understand what caused this though, but i don’t think it’s a good idea assuming or jumping to conclusion too early with small test even to give up on a toolkit you found with pleasure( i remember your excitement in shout area quite sometime back).
@urbankind I’ll report to jury, hope to win the prize!
The point with that patch is that instead of spreading values through phong fx, those were spreaded before sending them to it. And probably this is bad because effect had to manage manymanymany data, instead of producing them on its own rules, therefore asking for a lot of resources.
Probably those pins should not be spreadable, just to avoid noob-frustration, as I have now many more white hairs and deep wrinkles since I started with vvvv ;)
Sure you win prize if you find the missing pages! :P
By the way if you copy the nodes from the original poof’s patch posted here and paste in new patch, i find difference in performance… it gets much better without lag. This is the second time i encounter such behavior. Can you please clarify me on this regard?
copy paste:
if you look at a vvvv patch closely with any xml reader, you will find that a patch is an xml doc !
during wild patching, you are creating, destroying nodes, etc… and sometimes, you may create bugs and memory leaks
that may interfers in XML data in your patch, those leaks. but not so much, and only in rare cases.
copy pasting will only snap the ok nodes, no hidden things.
for beginners reading this topic:
usually , when you do a project, you will use 2 approaches after wild patching. Personnally i name it " cleaning"
-using debug mode ( see menus) will help you to determine what errors of code you are doing ( and please consider that most of errors are yours, and not vvvv, coming from your coding). The milliseconds informations is really usefull to help and determine quickly where you have loose of performance
-cleaning patches: once your patch is working, or you recreate it completely, to be sure no hidding bugs around, or you copy paste every body in a new blank patch to avoid any dirty things left from closing/destroying nodes done while live patching.
@urbankind, I just can guess, really. I’m not able to explain why or why not something happens: I take my exp and then guess something, since I’m not a programmer able to read a hlsl code, for example - and that’s why I started to translate wiki pages.
@karistouf I must say that sometimes vvvv as a “strange” behavior: I’m working on an onscreen keyboard which will have few functional keys for caps or special - @, €, # - chars. I found a bug in my code related to the way keys react on pressing, only after I renamed the main patch. In between there’s even been a few Windows restarts - before renaming main patch, I mean.
It happened that after modifying a section of a subpatch, the behavior of the whole patch changed just related to the changes I made, but in the renderer didn’t show the wrong behavior of keys. Then I found the “bug”, that obviously was my fault.
While trying to apply the change, I tried many solutions; when I got what I was looking for I integrated the subpatch with brand new nodes.
The strange fact about the resulting bug is that I had to do a “big” job to fix it: I had to “rewrite” the whole logic part pertaining the behavior of those keys.
It was like vvvv stored some data and didn’t update them, like a logical short circuit. Dunno, maybe related to temp files? Anyway I’ll do like this in future. Renaming patches and deleting temps - home made beta testing!
@poof
Nice work! would have been better if little effort was taken to change the aspect ratio to something wider than the original mod patch. However nice use of the patch and synchronize quite well with music. Cheers!
FOV scratching! And I liked the way you used two different light sources, one for the yellow, and one for the rest; in particular light scratching at 3.10. And you also played it live, I mean, it was not totally automatic! Great! Glad to be of some help.
May I suggest you to try to set to other value than NONE the Fullscreen or Windowed (it depends on what you use) Antialiasing Quality Level in the Renderer (EX9)? It’s just because it seems there’s no antialiasing, even considering eeootoobe’s rude compression.
Thanks! I would have made the window bigger but i didnt want fraps to stagger on my raid 1 (you can see it staggering when i started the music in the beginning). I didnt change much to the patch, just added another sphere and animated fov and yaw with an audio analysis. I can say its encouraging to make something with very little knowledge, but then again i just modified your patch. Now if i only understood how it worked…
