wallworm

I am trying to create a tree species that includes different life-cycle phases inside the single GrowFX rule set. What I am trying to do is create a randomization of these life cycle elements. For example: Saplings Young Trees Middle Age Trees Old Trees Dying Trees Dead Trees Ideally I want to expose Public Paramaters so that the user can control the percentage of these. For example: Saplings 25% Young Trees 15% Middle Age Trees 10% Old Trees 5% Dying Trees 20% Dead Trees 25% Furthermore, I would like to be able to change the material IDs of each tree based on this rule set. In fact, I want the phase (Sapling, Old, Dead, etc) to be able to affect the entire hierarchy of that particular tree (so every level of a Sapling tree will know to use a consistent sapling material ID set, etc). Not only IDs, I'd prefer to be able to make some paths non-spawnable in some cases (like maybe the dead tree skips the leaves paths, etc.) Is there a sample of something like this already? Thanks in advance.

I tested the new exposed methods and I had an issue. I ran the function and hit undo a couple times. This seemed to be OK. In the MXS listener recording below, I hit undo after the first two times running the $.CreateHierarchyMeshes() method. Then I ran the function to create again but stuffed into variable s. Then I ran delete s. I then assigned s again with another call to the method but got an EXCEPTION_ACCESS_VIOLATION: $.CreateHierarchyMeshes true #($Editable_Poly:Cupressus_3_001_1_001 @ [257.438660,64.907280,0.000000], $Editable_Poly:Cupressus_3_001_2_001 @ [257.192810,69.849075,114.265289], $Editable_Poly:Cupressus_3_001_3_001 @ [287.182556,18.811779,144.575912], $Editable_Poly:Cupressus_3_001_2_002 @ [258.417938,68.139091,137.432953], $Editable_Poly:Cupressus_3_001_2_003 @ [256.248108,65.852432,160.015427], $Editable_Poly:Cupressus_3_001_3_002 @ [196.211304,65.676514,157.349869], $Editable_Poly:Cupressus_3_001_2_004 @ [253.304810,63.673962,179.984283], $Editable_Poly:Cupressus_3_001_3_003 @ [298.677460,29.907063,190.718811], $Editable_Poly:Cupressus_3_001_2_005 @ [254.182571,64.322510,199.802017], $Editable_Poly:Cupressus_3_001_3_004 @ [255.555679,132.645004,225.532196], $Editable_Poly:Cupressus_3_001_2_006 @ [257.332092,65.911949,219.440674], $Editable_Poly:Cupressus_3_001_3_005 @ [193.613007,-13.574837,249.484070], $Editable_Poly:Cupressus_3_001_2_007 @ [258.979675,66.757721,237.858826], $Editable_Poly:Cupressus_3_001_3_006 @ [298.677948,80.205109,242.760712], $Editable_Poly:Cupressus_3_001_3_007 @ [354.107910,113.332748,239.344101], $Editable_Poly:Cupressus_3_001_2_008 @ [258.659760,69.174309,255.113449], $Editable_Poly:Cupressus_3_001_3_008 @ [196.943237,88.189751,254.227020], $Editable_Poly:Cupressus_3_001_3_009 @ [159.362885,105.001373,246.191406], $Editable_Poly:Cupressus_3_001_2_009 @ [258.801208,70.954430,269.943054], $Editable_Poly:Cupressus_3_001_3_010 @ [279.488220,38.815216,276.179779], ...) $.CreateHierarchyMeshes false #($Editable_Poly:Cupressus_3_001_1_001 @ [257.438660,64.907280,0.000000], $Editable_Poly:Cupressus_3_001_2_001 @ [257.192810,69.849075,114.265289], $Editable_Poly:Cupressus_3_001_3_001 @ [287.182556,18.811779,144.575912], $Editable_Poly:Cupressus_3_001_2_002 @ [258.417938,68.139091,137.432953], $Editable_Poly:Cupressus_3_001_2_003 @ [256.248108,65.852432,160.015427], $Editable_Poly:Cupressus_3_001_3_002 @ [196.211304,65.676514,157.349869], $Editable_Poly:Cupressus_3_001_2_004 @ [253.304810,63.673962,179.984283], $Editable_Poly:Cupressus_3_001_3_003 @ [298.677460,29.907063,190.718811], $Editable_Poly:Cupressus_3_001_2_005 @ [254.182571,64.322510,199.802017], $Editable_Poly:Cupressus_3_001_3_004 @ [255.555679,132.645004,225.532196], $Editable_Poly:Cupressus_3_001_2_006 @ [257.332092,65.911949,219.440674], $Editable_Poly:Cupressus_3_001_3_005 @ [193.613007,-13.574837,249.484070], $Editable_Poly:Cupressus_3_001_2_007 @ [258.979675,66.757721,237.858826], $Editable_Poly:Cupressus_3_001_3_006 @ [298.677948,80.205109,242.760712], $Editable_Poly:Cupressus_3_001_3_007 @ [354.107910,113.332748,239.344101], $Editable_Poly:Cupressus_3_001_2_008 @ [258.659760,69.174309,255.113449], $Editable_Poly:Cupressus_3_001_3_008 @ [196.943237,88.189751,254.227020], $Editable_Poly:Cupressus_3_001_3_009 @ [159.362885,105.001373,246.191406], $Editable_Poly:Cupressus_3_001_2_009 @ [258.801208,70.954430,269.943054], $Editable_Poly:Cupressus_3_001_3_010 @ [279.488220,38.815216,276.179779], ...) s = $.CreateHierarchyMeshes true #($Editable_Poly:Cupressus_3_001_1_001 @ [257.438660,64.907280,0.000000], $Editable_Poly:Cupressus_3_001_2_001 @ [257.192810,69.849075,114.265289], $Editable_Poly:Cupressus_3_001_3_001 @ [287.182556,18.811779,144.575912], $Editable_Poly:Cupressus_3_001_2_002 @ [258.417938,68.139091,137.432953], $Editable_Poly:Cupressus_3_001_2_003 @ [256.248108,65.852432,160.015427], $Editable_Poly:Cupressus_3_001_3_002 @ [196.211304,65.676514,157.349869], $Editable_Poly:Cupressus_3_001_2_004 @ [253.304810,63.673962,179.984283], $Editable_Poly:Cupressus_3_001_3_003 @ [298.677460,29.907063,190.718811], $Editable_Poly:Cupressus_3_001_2_005 @ [254.182571,64.322510,199.802017], $Editable_Poly:Cupressus_3_001_3_004 @ [255.555679,132.645004,225.532196], $Editable_Poly:Cupressus_3_001_2_006 @ [257.332092,65.911949,219.440674], $Editable_Poly:Cupressus_3_001_3_005 @ [193.613007,-13.574837,249.484070], $Editable_Poly:Cupressus_3_001_2_007 @ [258.979675,66.757721,237.858826], $Editable_Poly:Cupressus_3_001_3_006 @ [298.677948,80.205109,242.760712], $Editable_Poly:Cupressus_3_001_3_007 @ [354.107910,113.332748,239.344101], $Editable_Poly:Cupressus_3_001_2_008 @ [258.659760,69.174309,255.113449], $Editable_Poly:Cupressus_3_001_3_008 @ [196.943237,88.189751,254.227020], $Editable_Poly:Cupressus_3_001_3_009 @ [159.362885,105.001373,246.191406], $Editable_Poly:Cupressus_3_001_2_009 @ [258.801208,70.954430,269.943054], $Editable_Poly:Cupressus_3_001_3_010 @ [279.488220,38.815216,276.179779], ...) s.count 164 delete s 164 s = $.CreateHierarchyMeshes false -- Known system exception -- ######################################################################## -- Address: 0xa348d9dc; nCode: 0x00000000C0000005 -- Desc: EXCEPTION_ACCESS_VIOLATION The thread tried to read from or write to a virtual address for which it does not have the appropriate access. -- Read of Address: 0x0000000000000000 -- ######################################################################## -- MAXScript callstack: -- thread data: threadID:14720 -- ------------------------------------------------------ -- [stack level: 0] -- In top-level -- ######################################################################## -- C++ callstack: -- (GrowFX): (filename not available): CanAutoDefer -- (GrowFX): (filename not available): GetGrowFX2Converter -- (GrowFX): (filename not available): GetGrowFX2Converter -- (MAXScrpt): (filename not available): Generic::apply -- (MAXScrpt): (filename not available): CodeTree::eval -- (MAXScrpt): (filename not available): MAXScriptException::ScopedMXSCallstackCaptureDisable::__autoclassinit2 -- (MAXScrpt): (filename not available): Primitive::apply -- (MAXScrpt): (filename not available): CodeTree::eval -- (MAXScrpt): (filename not available): SourceFileWrapper::eval -- (MAXScrpt): (filename not available): IsMAXScriptListenerInViewport -- (USER32): (filename not available): GetMenuItemCount -- (USER32): (filename not available): GetMenuItemCount -- (USER32): (filename not available): GetMenuItemCount -- (USER32): (filename not available): DispatchMessageW -- (USER32): (filename not available): CallWindowProcW -- (UIControls): (filename not available): (function-name not available) -- (UIControls): (filename not available): (function-name not available) -- (USER32): (filename not available): DispatchMessageW -- (USER32): (filename not available): DispatchMessageW -- (USER32): (filename not available): IsDialogMessageW -- (3dsmax): (filename not available): XMLAnimTreeEntry::GetUnique -- (3dsmax): (filename not available): Frustum::operator= -- (Qt5Core): (filename not available): QObject::qt_static_metacall -- (Qt5Core): (filename not available): QEventDispatcherWin32::preProcessNativeEvent -- (Qt5Core): (filename not available): QEventDispatcherWin32::processEvents -- (qwindows): (filename not available): qt_plugin_query_metadata -- (Qt5Core): (filename not available): QEventLoop::exec -- (Qt5Core): (filename not available): QCoreApplication::exec -- (3dsmax): (filename not available): Frustum::operator= -- (3dsmax): (filename not available): NodeAndAnims::SetNode -- (3dsmax): (filename not available): UtilGfx::InitRectIPoint3 -- ########################################################################

Awesome. I'll test this week!

I just tested. The button now operates as expected. Thank you so much! I saw that the GFX interface includes functions for : getNumSequences() getNumLines() GenerateOneMesh() I expect that this is the methods that you go through to generate the meshes like in the one in the UI. I propose that the exact method that the UI uses is also exposed as a method as well. It would be nice to have an option: GenerateAllMeshes <asMesh=false> where the return value is an array of new nodes in the scene when asMesh=false and an array of trimeshes if true.

That is awesome. I didn't know about the random generator node yet. Perfect!

I would like a new option for UVs that will make it easy to randomize the offsets of UVs in a mesh per element. Something as simple as a Randomize for U or V checkbox for use in tiling textures. Right now it's sometimes hard to hide the re-use of the same textures across branches because they all have the same starting position in V across the meshes made from a distributor.

I didn't see your message. I'm using Max 2022/2023.

Eduard, In this example, there is one GrowFX object using a Point Distributor. There are three point distributor Points that create the yellow cones. The objects that are created have a pivot that is where the GrowFX node was (world origin in this case). When I moved them away, notice how the pivot is not at the object base, but offset. I'd like the pivots to be where the original distributor spawn was (base of each cone). In the case of a point distributor, I'd like the position and orientation to match that of the point helper that the point distributor used. Hope this makes sense.

Awesome, thanks!

Awesome. I cannot believe I didn't notice that! I would like to propose an option to make that function have the ability to set the pivot/transform of each object to match the position/orientation of the distributor point that made each object? Right now the pivot matches the pivot of the GFX object, and this isn't ideal for assets exporting into a game. Also, is the method of that button exposed to MAXScript?

In GrowFX2, if you click the Create button to create a new point for a Point Distributor, only the first point you click will work as expected when snaps are turned on. The following points will all be aligned exactly to the first point you create.

I would love to see a utility in GrowFX that would allow me to create a snapshot of each plant in a GrowFX node. By plant I would mean the complete mesh for each path up to the top parent. For example, in the image here, there is one GrowFX node. There is one root Point Distributor that then spawns 5 plants from 5 points. Each of the resulting meshes from those 5 root distributions would be turned into a single mesh with its pivot aligned to the transform of that plant. It would be nice to have this exposed as both a button in the modify tab as well as exposed to MAXScript. In a MAXScrtip call it would be nice to have: <node> GrowFX2.GetMeshes() returns array of the nodes created from the function. Thanks for the consideration!

Update: This problem seems to be related to some viewport settings. Ignore my question!

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.

Sorry it took me so long to respond. AWESOME!

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).

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).

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.

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.

Brilliant! I want my hands on it the second it's ready!

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.

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();

I'm just posting to see if there is any progress on this front?

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.

That's awesome. You're great!