jwiede

Member
  • Content count

    60
  • Joined

  • Last visited

Community Reputation

3 Neutral

About jwiede

  • Rank
    Neophyte

Contact Methods

  • ICQ
    0
  1. The ergonomics are no worse than actual painting, if you think about it. Holding up a paintbrush while painting onto an easel can also get tiring.
  2. One more minor request (it might be easy to do now, not quite sure): It'd be idea if we had a way to trigger an external program/script (with adjustable command line) as part of the events that occur when the user triggers AppLink on the 3DC side. I don't believe that can be done with existing features, can it? That way, using LW as an example, we could launch Lightwave directing it to use a specific startup script that knows how to use the output file to load all the exported data. By making the command adjustable, we could also put a script in-between 3DC and the other app to do any content mgmt tasks we might want to do like checkpointing the output file, etc. If we wanted to get fancy (example for Mac, but Windows WSH as feasible), we could have it trigger an applescript that checks if the app's already launched, and if so just signals it to run the import lscript, but if LW isn't running the applescript launches it and then signals it to run the lscript. Initially we could just get by with a preference for "what command to issue after AppLink export complete". Ideally, we'd either be able to select one of multiple app's launch profiles from a menu in prefs (allowing folks with multiple receiving apps to change which gets launched as needed, potentially even adding further automation).
  3. Ugh, someplace like "~/Library/Application Support/3DCoat/Exchange/" would be a much better place to put such data. By using a directory under "Applications" you run the risk of permission problems, as regular users aren't supposed to have r/w privs in Applications (admin users do, but not all users are admins in corporate environments). Similar problems exist for Linux users, and I guess "~/.3dcoat/exchange/" would be a nice equivalent location on Linux. That way, they're both in locations where even regular users have write privs. Thanks!
  4. Andrew, this doc makes reference to a file location that only exists on Windows. Where is the corresponding location on OSX (and Linux)? Can you please add that information to the document? Thanks!
  5. cakeller, I might be missing something, but I keep noticing you're using the lerp() function in the GLSL version of the fragment program. While I believe Nvidia just invisibly translates lerp() to mix(), technically there is no lerp() function in GLSL, the proper function you want is mix(). The ATI 4870 OSX drivers do not appear to invisibly translate lerp() to mix(). Another problem is that you use trunc(), which is only supported in the most recent releases of GLSL (and not those provided by ATI on Mac, as far as I can tell). Replacing all instances of lerp() with mix(), and trunc() with floor() appears to get both the SM_Utility and SM_SUPERSHADER shaders to work as expected on my Mac (MacPro running 10.6.2) and ATI card (Apple ATI 4870).
  6. I've run into some odd problems with both the SM_Utility and SM_SUPERSHADER under Mac. Both seem to have rendering problems where the object's voxels wind up transformed almost entirely off-screen, where the SM_Bronze shader appears to render the voxels in the expected location. I've included a screenshot of what happens with the SM_Bronze (good) and SM_Utility shader below (SM_SUPERSHADER has same visual outcome as SM_Utility shader).