|
|
Unsupported — We cannot guarantee that this software will work properly on Mac OS 10.8 and above. Please be careful.
Release: Texture, v0.4
Release Type:
Production
Version:
0.4
Release Notes
This is the first public release of our "Texture" patch --- a set of 26 patches for procedural texture generation, using techniques derived from Perlin Noise. This is pretty much a 1-to-1 translation of the excellent libnoise project, so the standard libnoise documentation applies verbatim. Unlike other patches, this patch is LGPL consequent to libnoise being LGPL. Known issues:
Installation InstructionsPlace the plugin file in |
Demoscene flashback.
or something.
The method you'll want to implement is
which receives null (not nil) when disconnecting.
[further research] -- I didn't like the idea of using a private method if there's a more "standard" way of doing it. Anyway, here are a couple backtraces from when that method is called, so you can go higher up the call stack if you'd like. It doesn't appear to be a port-level notfication, but a patch-level one?
[connecting a texture to a port:]
[and disconnecting said texture port:]
Have fun, please document what you find :)
Thanks... I had already tried all the deleteConnectionForKey methods, but wasn't able to get any to trigger. (Apparently the default method in the "QCPatch(Override)" category has precedence over the method in my KinemeTexturePort subclass? I'm not certain of the semantics of this...)
But the _setConnectedPort does indeed work:
- (void)_setConnectedPort:(QCPort *)port { [super _setConnectedPort:port]; // if the port is disconnected, i (manually) reset myself if(!port) [self setTextureValue:nil]; }QCPatch is not in the ancestry of KinemeTexturePort, QCPort is. I don't know that the port methods get called all that often? or maybe I'm completely mistaken. shrugs
err. i'm blind. lemme try that again..
No, that was just a typo. I mean, "Apparently the default method in the "QCPatch(Override)" category has precedence over the method in my TexturePatch subclass?"
I meant TexturePatch, not KinemeTexturePort.
Doesn't work if I try to override deleteConnectionForKey in TexturePatch.
Aren't categories automatically prioritized over non-categories? (causing all those cool injection hacks from the podcasts, including namespace trampling)
maybe try including the category name for that method in the implementation line?
Yes, you're right.
So, I can do this:
@interface QCPatch (KinemeTexturePort) - (void)deleteConnectionForKey:(id)fp8; @end @implementation QCPatch (KinemeTexturePort) - (void)deleteConnectionForKey:(id)fp8 { ... }But now the fp8 is just an NSString, and I need some way to resolve this into an actual QCPort instance. Investigating..
Inside the above deleteConnectionForKey, self points to a null patch instance. Weird.
That's stumped me then. I was going to guess you'd do something like
[self objectForKey:fp8]or something similar... but without self... hmm :)Aren't you doing categories kind of incorrectly? In other words, shouldn't it be a TexturePatch method, with maybe the same category as the original? the category name is probably superfluous, but the object might be something significant...
well, i mean, self != null, but if you do
it prints out "<QCPatch = 0x15F4AFC0 "(null)">".
Anyway, "objectForKey" doesn't work, but "linkForKey" does. And QCLink is a thin wrapper from which it's easy to extract the QCPort.
So, the following code works:
@implementation QCPatch (KinemeTexturePort) - (void)deleteConnectionForKey:(NSString *)key { QCPort *p=[[self linkForKey:key] destinationInput]; // if this is a KinemeTexturePort, i (manually) reset its value if( [ [p class] isSubclassOfClass:[KinemeTexturePort class] ] ) [p setValue:nil]; [super deleteConnectionForKey:key]; } @endI don't want to attach the Category to only TexturePatch because not all of my patches are derived from TexturePatch. (Though perhaps I should add another class from which all of my classes inherit, and attach the Category there.. I'll try that.)
And I think naming the category KinemeTexturePort is conventional, as category names I've seen seem to be arbitrary strings that indicate scope/function.
I tried making a common base class and attaching the deleteConnectionForKey category there, but it isn't triggered. So it looks like we'll have to keep it attached to QCPatch.. :^(
Category on QCPatch is probably not the correct way to solve this problem. It also doesn't work in Leopard :)
By making KinemeTexturePort a subclass of QCStructurePort and using its internal class variables for storage, we get correct behaviour without hacking a category onto QCPatch. This means either A) we're doing it wrong or B) QCPatch already handles every existing port type, but not additional ones. I can't see why they would do this though, when every other non-number type of port appears to exhibit this common behaviour. Perhaps it's a QCObjectPort subclass thing?
some disassembling of deleteConnectionForKey shows no such class-specific behaviour.
[Later: yep, properly inheriting from QCObjectPort gives us correct behaviour, without all the hackery]
[from a discussion @smokris and I had while driving to work this week]
Having the texture renderer render in a separate thread would help the UI not stall when starting up or while rendering difficult textures.
Provide an option to render at lower resolutions at first, to give that "Netscape over dialup" incremental detail feel :) This would have a side effect of trivial mipmap generation.
And, of course, converting the texture to GLSL shaders would make for true infinitely detailed textures. This might not always be possible though, but would be an interesting exercise.
Have the renderer's state store the output, to prevent regeneration after each startup.