You could make a product that requires a UV mapper instead. For example, a light mapper. It seems that illuminate labs doesn't seem to have trouble selling theirs. Computing the lighting is fun on its own, but parameterizing the lightmaps in such a way that minimizes texture use while avoiding seams is a much more challenging problem.
Yeah, I'd love to do a light mapper. I think there's a lot of interesting work to do in that domain. (signal-specialized parameterization and whatnot ; synthesis from photon casting, denoising, etc.)
BTW I saw the NVidia ray caster was announced publicly. That seems like a very nice utility.
Yeah, I'd like to write a small raytracer myself. It will probably be one of my next free time projects.
The IRT API is very promising, we integrated it into our baker tool about a year ago, and were getting good speedups on G80 vs. the latest Core2 Duo. It was however very unstable.
I don't want to recommend it very highly until I revisit that code again and get some accurate performance numbers, though.
Ugh, I meant "small lightmapper", instead of "small raytracer".
March 2, 2009 at 5:43 PM
Intel used to do a pretty good thing where they would write nice like optimized widgets for their chips and
give them out as source code to developers for free. Obviously that makes a lot of sense in their business,
it sells more chips.
Now they want to
charge me for the optimized math
routines !? WTF Intel !? And even if I buy it, I don't get source code, I just get DLLs. Not just DLLs,
a HUGE MESS of DLLs - 118 of them taking 283 Mega bytes !
Granted, the "IPP" does a whole lot of stuff. It's got jpeg, H264, MDCT, MP3, hell it's got CELP, BWT, it's
got like every damn thing in the universe, but it's all useless because it's not cross-platform, it's not
source code, and it's a huge complex system.
Give me little isolated code snippets that just do the one thing I want to steal. Don't force giant systems
on me.
I want a good little nugget of *functionality* , not a framework. I have my own framework.
I've been thinking about this a lot recently because to some extent the way I'm writing Oodle right now it's
becoming a framework. I think it's becoming pretty good, it's getting to be pretty easy to make really cool
stuff happen, but nobody wants to buy a framework. Nobody wants to have to buy into a "system" that will make
their life easier - they want to have their own framework and just call you for the little bit of hard stuff
they don't want to bother with. I need to make sure Oodle does that.
The danger for me is that I really like writing framework code. The way I like to code, I build up a huge base
of really strong fundamentals into a whole system that does everything I want, and then I can just easily tack
bits together to make application functionality. So maybe 90% of the code is "library" or "framework" and the
glue and application is minimized.
Like to do my new vert snapper for galaxy it was like - I already have my hash map, I already have my int geometry
quantizer, boom tack it together, it's like 20 lines of code. That's awesome, but to share that code you have to
buy into my framework - if you try to pull just the vert snapper, you find that it's got roots that go deep into
the earth of the framework and cling onto the vector, the int vector, the int-float math, the hash map, the std::vector,
my template util set, etc etc you probably wind up with 20 files.
I wish you could sell mesh algorithms. Just looking back at Galaxy to do the BMP triangle removal makes me miss it;
the algorithms are really complex and interesting, the results are concrete and compelling, and there's so much more
to do. I just don't see how
to make it a product. Like for example a really good UV mapper I think would be a great product, it's hard to do,
it doesn't really exist, and everyone needs it. But they don't know they need it.
"02-27-09 - Why is Intel selling me Software -"
4 Comments -
You could make a product that requires a UV mapper instead. For example, a light mapper. It seems that illuminate labs doesn't seem to have trouble selling theirs. Computing the lighting is fun on its own, but parameterizing the lightmaps in such a way that minimizes texture use while avoiding seams is a much more challenging problem.
March 2, 2009 at 4:24 PM
Yeah, I'd love to do a light mapper. I think there's a lot of interesting work to do in that domain. (signal-specialized parameterization and whatnot ; synthesis from photon casting, denoising, etc.)
BTW I saw the NVidia ray caster was announced publicly. That seems like a very nice utility.
March 2, 2009 at 4:51 PM
Yeah, I'd like to write a small raytracer myself. It will probably be one of my next free time projects.
The IRT API is very promising, we integrated it into our baker tool about a year ago, and were getting good speedups on G80 vs. the latest Core2 Duo. It was however very unstable.
I don't want to recommend it very highly until I revisit that code again and get some accurate performance numbers, though.
March 2, 2009 at 5:39 PM
Ugh, I meant "small lightmapper", instead of "small raytracer".
March 2, 2009 at 5:43 PM