Forum Replies Created
-
Posts
-
Kineme3D works in 10.8, but Kineme doesn’t officially support it, probably for a variety of reasons but as much related to them spending time developing VUO as anything else.
You can use the v002 patch and get different images on the model by connecting a patch that outputs image, to the input image port on the v002 model importer. In some cases, you may see some colors of the image seem to paint the model in an unfocused way – this will often occur if a model doesn’t have any “uv coordinates”. UV coordinates dictate how the texture is applied to the model; what parts of the image go where, wether parts repeat/tile, etc.
The simplest way to apply lighting effects to a model would be to use the built in QC Lighting Environment patch. This is a pretty common, basic, lighting scheme.
The only way you can really get fancier lighting or textures going, would be to put the model importing patch inside of a GLSL shader environment. However, at that point, you will be responsible for adding code in the vertex and fragment shader sections of the GLSL shader that dictate how the model is lit (vertex and fragment), how it is textured(fragment), and potentially how any deformations/warps happen(vertex shader). A glsl shader can be responsible for providing all values to create lighting, or it can potentially be placed inside of a Lighting Environment and “get” the values state of the Lighting Environment via GLSL code, to create an idealized Lighting Environment. That’s all a bit more “coder” and a bit less “designer/artist”, but there is quite a bit of info out there about shaders like that, and Apple also originally supplied many shader examples formatted for use in QC.
Thanks for the feedback.
To be clear, I didn’t say profiling is for morons; that’s crazy talk.
I made some comment about profiling in editor. When I’ve profiled in Editor and filed bugs in the past, the response was to not profile in editor, because of a number of issues. Profiling in the simplest possible app (commandline preferably) was described as the valid way to peg down bugs. That makes sense to me. I meant something more like “if one has been informed of that, and continues to do otherwise, they are a moron”. If one is not aware of that, like I was not at one time, they are a newb in that area. If that’s an unfair or inflammatory statement, apologies, but I was in a little irritated state after having been told I was an idiot on public forum after sharing files privately.
I really respect your work and am a fan; I enjoy your sense of aesthetics, and am saddened by your public reaction after sharing some files privately.
Yeah, sending you a profile would take a trivial amount of time, but I guess I’m not jumping at the chance at this point.
I also never claimed the issue was common. I came on forum asking if it’s ever come up before or was expected.
Have a good one.
Here’s my outlook on it at this point.
I came on here and mentioned something I was seeing with performance. I asked “is that something that has popped up before, and/or could it possibly have to do with OpenGL Scene grab.”
Keep in mind, I’ve mentioned bugs about the OpenGL screengrab screwing something with texturing and mesh creator up, with whatever you had going on in previous versions, that my merely mentioning wound up with a solution. If I *did* send a sample, I don’t think I simplified it… I just sent it along in an advanced form, because *sometimes bugs result from non-simplistic combinations*.
With that in mind, I felt like the appropriate *starting point* was to go ahead and send along the project, as well as separating out some of the critical qtz resources. So it uses half a dozen plugins or so, and it didn’t have some non-essential stuff carved out.
If that was too much to handle, I’d tend to expect an email like “please trim some stuff, this is hard to sort through”, not the reaction that happened. I can be pretty snappy sometimes, so I kinda get it, but nowhere has being a know it all ass with knee jerk reactions been ordained cool or a positive characteristic.
Believe it or not, this is a pretty regular starting point for me with a number of these kind of bug scenarios, and I’ve dealt with plenty of people that actually do *not* have problems with files being reduced… because they aren’t overwhelmed easily, and take pride in their work actually working in complex scenarios as well as trivial ones. I’ve worked with other people at private companies that work on QC based tech, or people within Apple on such issues, to resolve bugs. Very often, from the most complex project, with no reduction *at all*, the bug can be sussed out.
At no point does private file exchange result in knee jerk whiney reactions, where privately exchanged files are arbitrarily panned with pretty insulting verbiage, *in public”, when I’m dealing with Apple or other companies or co-workers that I hold in high esteem, or simply know what professionalism is.
Maybe I have an unrealistic expectation of professional decorum. One, you may be entirely wrong in your assessment because you’re only looking at the scenario through your experience and the myopia of your view. Secondly, even if you were actually right, it’s highly untactful and unprofessional.
I’d advise other people who inquire about function and submit any kind of files or source to consider the reaction here. If someone has their panties in a wad, or the composition boggles their mind or simply doesn’t jive with their sense of style, you’re probably letting yourself in for a joyful public airing of that *opinion* instead of more discreet and professional private contact, in the same way that the file was sent (privately). That’s obviously pointed at this particular scenario, but there’s some universal truth in that.
After that kind of treatment, it’s not like give a flying fuck if your plugin works or it doesn’t. In some scenarios, it being turned on flips out CPU consumption. FACT. I’m not really interested in helping one damn iota after the really cheap slamming on your part.
Further, you have to be FUCKING KIDDING ME.
We’re talking about four comp loaders, and a shit ton of some multiplexing, admittedly, but that’s the only thing that someone could go “woah” about, and my experience and testing let me to that. It’s not some design or route I pulled out of my ass on whim. It’s the result of a *actually taking the time* to create a variety of approaches, and one without one lick of the multiplexing stuff you probably took a shit when you saw. I had one iteration of that was much different, and without one lick of multiplexing, and strung some renderers together. It was *not as fast*, using multiple alternative routes. That the Editor in Lion takes a shit when you try to look at it… is sad, but that take was expressed after you deciding it would be really cool to foam at the mouth some, as was the request for other profiling. That anyone would go “ohhhh, it’s a lot of multiplexing, how can you expect Syphon would work!”. REALLLLLLY?
REALLLLLLLLLLLLLY? Sure, that makes a ton of sense.
So, it could take about 5~10 minutes to send you some files, but DO NOT GIVE A FLYING FUCK at this point. I spent a bit today setting up something similar using standard API’s and it worked fine. That seemed like a more productive move for me. Again, if I have the time and the mood strikes me to do some charity work, I’ll give it a look again and push something to git or wherever the hell you host it. Seems more constructive than getting raked over coals for no reason other than some weird sour grapey vibe.
Yeah, it’s absurd.
I’m trying to debug errant behavior in *an application* that also occurs in *the QC editor application* when running a “qtz file” that my app uses as a resource.
QC has additional stuff going on with the Editor and problems leaking with various *stock patches* that don’t leak outside of the QC editor environment, that profiling in QC is pretty much a waste of time when the baseline is going to show a bunch of leaking and foul shit when profiling a frigging two patch composition. What would the best valid test, would be to suggest to run the qtz via the simplest possible program that can run it, not to run it in a program with known bugs and leaks (eg., QC Editor). Yeah, only a naive newb, or “total fucking moron”(as you put it) would be profiling a qtz in Quartz Composer editor.
I explained that pretty clearly, and am at a loss as to your motive or lack of understanding in convoluting that. It doesn’t mean I have ambivalence about profiling, or think profiling is moronic.
If I was to submit a file to Apple, I’m pretty sure they wouldn’t pop on the Apple forum and rip me a new asshole b/c of a matter of opinion , or even fact.
As far as your inflammatory comments go, it’s good to know you have the ear of the QC Gods the have bestowed upon you the supreme knowledge of what they did or didn’t intend.
@ Brian, yeah, the don’t be dumb suggestion is always a good one 🙂
@ Vade, you phrase your opinions in a pretty damn inflammatory way, and you’re still doing so: “is just not a sane way to work, regardless of the percent or two difference the non encapsulated macros get you.”
1) My mind isn’t boggled by the comp; I find it to be simple and I also don’t have any problems editing it on my system.
I provided the full comp before cutting stuff out, mainly because I didn’t for a second think it was going to get this kind of awesomely professional public reaction.
I did provide ample with how to recreate the issue – with Syphon Server toggled on, CPU jumps 100+%. That’s how to recreate it – turn on Syphon.
In the email along w/ the file, I explained the bit about loading some external qtz’s from a folder. I included the main qtz in question, the folder of modules, as well as the actual Xcode project.
2) I gave you quantitative data about the average percentages of difference. If we’re on some kind of non-trust system where I absolutely have to take screencaps….OK.
3) Please. That is so patronizing. I explained to you that with Syphon ON, GL Profiler crashes on my system. Maybe I should have gone the extra step of detail to inform you that GL Profiler works without it ON and when profiling other stuff, but I thought that was implicit in the statement that I’d done profiling earlier, before introducing Syphon.
Profiling in the QC Editor *is* useless, in general, because it has various leaks and bugs. Anyone who makes a point of regularly profiling in the QC Editor is either a naive newb, or an idiot.
Vade: “After spending a few moments looking at that comp, I am going to go out on a limb just frankly say, that is totally not how QC is intended to be used. My brain hurts that anyone would even make a comp like that, and then complain about odd behavior.”
I love this part in particular. It’s just a frigging plist dude.
I didn’t report this to be a shit magnet, I reported it to give a head’s up about a potential issue. Whatever floats your boat.
I’ll be rushing to do that considering the super professional genius guy public response and calm non-knee jerk reaction that my privately emailed dl-link was met with.
…and of course I must have made the composition in some mystical way that can’t run in the Editor. Sure, that makes sense.
..and of course it’s realistic for a project to have no external dependencies and legitimate bugs don’t count if they are brought on by code not working correctly with them. So you can rule out any bugs caused by a swarth of patches that… load files from external locales or should play nice together. Yep.
Thanks for the offer, but it’s sounding more likely that I’ll be able to pin down the bug. If it’s a Syphon bug, I’ll submit it to github, if it’s caused by a patch combo with a stock or third party patch, or hardware configuration, I’ll post back here.
Thanks for giving that a run, and the feedback. It’s good CPU consumption is modest either way on your machine.
After the really fun slamming, I kinda want to go on a jag about how little time it takes for a plist like this to load, the fact that keeping stuff “un-macro’d” makes for faster performance ultimately as opposed to “nesting” stuff in macros, that most of the noodle-adge here that’s involved is with multiplexing that’s extremely lightweight on cpu, that this is faster in performance than loading separate qtz pieces and stringing them together to achieve similar function, that the finished product renders visualizers in HD at a faster FPS (usually around 60fps for majority of my comps) than popular products I’ve used, and that today someone was checking it out and it had less latency than the sound system…. oh, I just did. 🙂
…but hey, I just do this for fun.
My brain hurts that you think that’s a reasonable reply to another human being. I’m not here going “oh, Syphon sucks because it causes a 100% cpu spike that can be pegged down to IT running”. If it floats your boat to be patronizing, I’m glad to have given you your opportunity for the day.
Mmmm, what’s essentially four comp loaders, loading some compositions that are shaders with grids. Yeah. Okey dokey.
Well, I was just doing that but to my chagrin, when I run GL profiler on QuartzComposer.app running the qtz in question (at least on one of my 10.6 partitions, usual “go-to” install, but not entirely “clean”), and Syphon is on the Editor, QC crashes. So, that’s obviously awesome help in pegging this down.
On that note, I’m going to do a little more due diligence and make sure I’m up to date, and give it a run on another 10.6 partition and 10.7 as well. My main question was “has this come up/is it expected with OpenGL Scene grab?”… guess it isn’t, which is good!
…and yeah, my app runtime (not QuartzBuilder-only use that for quick convenience builds or a/b-ing) manages to make the result much less noticeable than in QC editor.
I’m going to go ahead and send along the patch, because even though there’s a decent amount of patches, a bunch of it is stuff for contouring some control from external sources, and it’s pretty well metadata tagged, and one macro level… maybe I’ll just chop some of that stuff out first.
Lol…BUT, the data is factual and quantifiable. I see what you mean either way, not splitting hairs, just trying to make it easier for you to find the bug.
Sure. I was throwing out a general description to get feedback on if there where already any known issues.
I’ll look at editing non-essential parts out of the main qtz if that works, or send along the qtz in question if it winds up being some weird mix of circumstances that result in that.
@ bangnoise – I’m able to reproduce it in QC, where it’s actually much worse (around 40% CPU jumps to 170% with Syphon). I hadn’t profiled in QC, because it’s usually pretty worthless to do in-Editor profiling. That said, it’s a largish composition, so I’m trying to figure out exactly what it is that triggers this. I know that removing Syphon from the equation removes the problem, but I’m not running into the same thing with some simple tests. The premise of the composition is largely multiple composition loaders, loading other qtz’s that are mainly glsl shaders with stuff happening in the frag shader. I’ll see if I can contrive a simpler composition or home in on what it is that triggers this in combo with Syphon.
@ Vade- no, I’m just running on a single GPU, and that’s a good point about GL Profiler. I hadn’t run it on this particular project since adding Syphon.
I’m kind of surprised to think of that shader program as being very intense.
On a non-Syphon note, try changing the depth parameter to something like 8~10 instead of the current. The lower that number, the less iterations of spheres will happen, and the fragment shader will tend to perform more quickly.
If you need to use the Google Chrome engine, you can try using Syphon with the ofxBerkelium addon, which is powered by the Chrome engine.
I remember looking at that along time ago – that method has been deprecated for a bit, but Vade has the cleaned up version (I think?) in his Blurs source. If not, I remember when I was using that Rutt Etra project for a playground awhile back (sorry Vade, it did help me learn a lot though), I manually figured out whatever it had to be by checking Apple’s notes, so if you still have that source, a correct method is in there.
Well here’s the thing –
I’ve tried a few routes, all of which, on my nVidia 9400/9600 combo are non-trivially faster.
First off, I am always using a gaussian blur, for the smoothing of vertices effect, ala the way that you’ve traditionally done with Rutt. Interestingly, if I sub in v002 blurs, I get a trivial hit in performance (2~4fps), as opposed to using CI Blur with image dimensions/crop.
If I use a GL Polygon mode for my “wireframe”/”point” stuff, I’m seeing a hit of maybe 2fps. Totally negligible.
However, that doesn’t give all of the nifty scan line type options.
So, in adding in Lattice type of GLSL effects to the extrusion shader so that I can get horizontal or vertical scanlines, as well as “square” wireframe look (and other looks that aren’t available with rutt), I am still getting faster fps.
If I put the shader around the David Langford’s weighted grid generator instead of the normal GLSL grid (again, for scanline type effects)… again, way faster.
Bumping up resolution on the GLSL Grid/Shader combo to 256 produces almost no hit. On the Rutt, there is more disparity with resolution and fps.
My tests resulted in something like 12~15fps on HD material with Rutt, vs. an easy 30fps+ with GLSL.
No, I haven’t posted it anywhere, I’m working on it for a project.
Thanks. Again, it’s not really worth headaches, b/c it’s a very limited case scenario (as I’m sure you saw from my email explanation). If it’s a small fix, it would be cool.
I’m sure you’re right about Apple not giving any examples of image processing effects… the only apple example that processes image that I’m aware of is the FreeFrame example, and that’s sort of brain-damaged and has always had bugs, so maybe that’s why you don’t include it. There is also Histogram Operation project that processes image, but I remember performance on that being totally lacking, at least back in Leopard.
