Jump to content

wallworm

Members
  • Posts

    67
  • Joined

  • Last visited

  • Days Won

    4

wallworm last won the day on September 11 2019

wallworm had the most liked content!

2 Followers

Contact Methods

  • Website URL
    https://wallworm.com

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

5737 profile views

wallworm's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done
  • One Month Later

Recent Badges

5

Reputation

  1. Update: This problem seems to be related to some viewport settings. Ignore my question!
  2. I am curious about a problem where Vertex Colors sometimes stop working. In many cases when using the various vertex color nodes, the colors stop displaying in the viewport and renders (when using the vertex color channel in a texture map). Is there something to do to force vertex colors to be properly calculated? I've seen this problem where the vertex colors look fine, but when closing Max and re-opening the scene, the GrowFX node no longer generates the vertex colors.
  3. Sorry it took me so long to respond. AWESOME!
  4. It would be nice if GrowFX had a library browser similar to the one that comes with Forest Pack. It would be nice also if GFX would come with a preinstalled collection of plants in a default library. Finally, it would be good if you could add paths to GFX libraries that might be shared (on the LAN, for example).
  5. Yeah, that's probably correct. I noticed it doesn't detect this class. I think it may be that they are scripted geometry objects. The meshes are actually generated with the SDK but then used in the buildmesh of the scripted class (this is more convenient for my needs as developing UI and scripted functions is so much easier/quick in MAXScript).
  6. Eduard, I see that in your screenshot above the normals do seem to follow the transforms. I will have to see what might be different in my scene.
  7. Eduard, Thank you so much for looking into this! I tested the new version and have a few items to suggest. I noticed that the function only works if the source geometry has an edit normals modifier. This is an OK assumption but there are certain geometry types that are always explicit normals and perhaps they should not require the modifier. One important to me is WallWormMDL geometry class ( class id of #(0x4e8b048c, 0x732e564d) ). Others that might also want to be automatically using this is Linked FBX geometry. There are probably others. This is just a convenience idea. I noticed that the normals always point toward the original direction of the source normals in the world. In other words, they do not change orientation with the geometry as the objects are transformed from the distributors or morphed by modifiers. This leads to unexpected lighting. This issue is very important to address. I think that the second item might be computationally expensive but it is certainly necessary to get the results desired.
  8. Brilliant! I want my hands on it the second it's ready!
  9. That's awesome Eduard. I wish I had discovered this in my tests over the last two years! Note, it would be ideal if work on this includes some of the options in post #2 above for standard leaves and leaves meshes. Being able to make game-friendly normals especially for the low poly standard leaves would be a godsend. I would even add a couple new options than in list above: Out From Mesh Center Out From Element Centers.
  10. Here is a snippet of code for setting the explicit normal of Mesh class mesh (I yanked this from one of my plugins, hopefully it makes sense even if out of context): // Normals mesh.SpecifyNormals(); MeshNormalSpec *normalSpec = mesh.GetSpecifiedNormals(); normalSpec->ClearNormals(); normalSpec->SetNumNormals(numVerticies); normalSpec->SetNumFaces(numFaces); //verts for (int vertID = 0; vertID < numVerticies; ++vertID) { //here you would set verts, uvs //now set normal normalSpec->Normal(vertID) = Point3( normal, normaly, normalz); normalSpec->SetNormalExplicit(vertID, true); } // Face indicies for (int i = 0, j = 0; i < numFaces; i++, j += 3) { //set face verts, mapping, smoothing //now assign MeshNormalFace &normalFace = normalSpec->Face(i); normalFace.SpecifyAll(true); //below n0,n1,n2 would be index of normals normalFace.SetNormalID(0, n0); normalFace.SetNormalID(1, n1); normalFace.SetNormalID(2, n2); } //near end before invalidating geom or top caches normalSpec->SetFlag(MESH_NORMAL_MODIFIER_SUPPORT);//Might be necessary to keep normals and edit them normalSpec->SetAllExplicit();
  11. I'm just posting to see if there is any progress on this front?
  12. While I'm a general fan of node-based editors in many situations, and I do look forward to it in the context of GrowFX, I personally appreciate that Eduard and team have been adding new features into the current version. Many new features have saved my ass in the last year as they have been specific tasks I needed to solve and Eduard added them. I 'm personally highly thankful that new features have continued to come along. I look forward to V2. But for me I'm thinking that the node system itself is a big enough feature, by itself, to warrant a new version. I think that GFX has one of the best track records of customer support of any company I've dealt with--and a large reason for that is quick responses of features to solve customer problems.
  13. Furthermore, since you might be using masks from other channels (instead of channel 0, you might use another channel like a UVW channel instead), there should be a Channel spinner that defaults to channel 0 (which is the vertex color channel). Changing to channel 10, for example, will use the uvw coordinates as colors. For example, you can use Vertex Paint Modifier to paint vertex colors into channel 10 (or any channel).
  14. I meant to add: So the Surface distributor would need a new Dropdown under the Use Vertex Color checkbox with these options: RGB (default and legacy) Red Green Blue
×
×
  • Create New...