Itoo Software Forum
Forest Pack => Forest Pro (*) => Topic started by: TL1895 on July 03, 2015, 10:47:22 PM
-
scene suddenly started to crash early during light cahce.
now cannot render the scene at all. Now I open it and get this warning, followed by more warnings, then "try to save and quit?" dialog.
finally max closes to desktop with error message.
File: ..\..\common\util.cpp
Line: 1400
I may still be using 4.4.0
-
Hmm, turns out the scene got corrupted by some vraypatterns.
Sorry itoo, not your problem!
-
After we got RC and FP i got some crashes here too.
That may be the same.
It happens when selecting FP objects or during save "error writing file".
Our studio has a lot of scripts in use so there are several callbacks and pre/post renderscripts.
Maybe the crashes are related with the scripts.
EDIT --------
Im on Win7x64 Max2014 VRay2.50.01 FP4.3.7
Just updated FP to 4.4.1, ill give feedback on that.
-
By the way. If the crash happens in a maxfile, it does continue to crash everytime you select the object for that maxfile.
The only thing to go on with working in that file is to merge all stuff to an empty file.
Feels like it has something to do with persistant stuff that stays saved in the maxfile.
-
Even after updating FP to version 4.4.1 max is very unstable and keeps crashing when i select the FP or the distribution object.
I got a Maxfile aswell the minidump and userinfo.xml ready here to nail down where that behavior comes from.
Whom should i mail these files ?
-
Please send them to support@itoosoft.com. For large files, please use a web sharing service as WeTransfer or Dropbox.
Thanks,
-
Thanks, we have received the files.
According to the minidump and the screenshots, Forest cannot load the geometry templates and distribution maps because the file names are corrupt. These files are listed here:
C:\Program Files (x86)\Itoo Software\Forest Pack Pro\distmaps\index.dat
C:\Program Files (x86)\Itoo Software\Forest Pack Pro\geometry\index.dat
Please, check if you can see the content using a text editor. If they are correct, then for some reason the names are corrupted once loaded by the plugin.
This is a very unusual problem. Something must be interfering with the loading of these files, but seems specific to your configuration.
-
I think everything is fine in this files.
distmaps\index.dat
Name;Bitmap
Very Scattered;vscattered.bmp
Scattered;scattered.bmp
Spread 1;spread1.bmp
Spread 2;spread2.bmp
Spread 3;spread3.bmp
Spread 4;spread4.bmp
Dense;dense.bmp
Full;full.bmp
Groups 1;groups1.bmp
Groups 2;groups2.bmp
Grid 1;grid1.bmp
Grid 2;grid2.bmp
Grid 3;grid3.bmp
Isle 1;isle1.bmp
Isle 2;isle2.bmp
Isle 3;isle3.bmp
Horizontal Band;hband.bmp
Vertical Band;vband.bmp
Random Bands;bands1.bmp
Vertical Line;vline.bmp
Horizontal Line;hline.bmp
Sine;sine.bmp
geometry\index.dat:
Name;File;Object;Bitmap
One Plane;geometry1;ft_one_plane;one_plane.jpg
Two Planes;geometry1;ft_two_planes;two_planes.jpg
Three Planes;geometry1;ft_three_planes;three_planes.jpg
Four Planes;geometry1;ft_four_planes;four_planes.jpg
Curved Plane;geometry1;ft_curved_plane;curved_plane.jpg
Low Animated Plane;geometry1;ft_one_plane_anim1;one_plane_anim.jpg
Medium Animated Plane;geometry1;ft_one_plane_anim2;one_plane_anim.jpg
High Animated Plane;geometry1;ft_one_plane_anim3;one_plane_anim.jpg
Simple 3D Tree;geometry1;ft_tree1;tree1.jpg
-
Yes, the files are correct. Definitively the problem happens on a specific data structure, which is saved with the scene.
But i can load it here without problems, using your same configuration. Did you try to open the corruped scene from other computer ?
-
Sry, i dont tested opening the file on a different machine. We are just in production and all workstations are bussy.
I even got the following behavior on one Maxfile.
Cause FP makes this problems, i saved these objects to an XRefscene.
The MainFile loading the FP_scene renderes okay. Even in highRes with PSD Manager etc..
But it crashes "could not write File" if i try to save the MainFile under a different filename.
If i only disable the FP_scene in XRefScene dialog, the saving works without problems.
Enable it again and it renders fine. Very strange !
I Just gut permission from officehead to test Vray3 in terms of rendertimes and comparable renderresults.
So we may switch that in some days.
I'll stay active here for we need to nail down that problem.
-
Back from projecttasks, here is an overview what callbacks currently running in 3dsMax.
unitsChange:
id:#PhysXUnitChange, "PxUnitsChange()"
spacemodeChange:
id:#PhysXPlugin, "px_stopSimulationForEditing()"
systemPreReset:
id:#PhysXPlugin, "px_systemPreReset()"
systemPostReset:
id:#PhysXToolPanel, "PxPanelClose()"
id:#vfb_rollouts, "VFB_methods_struct.Reset()"
id:#PhysXPlugin, "px_systemPostReset()"
systemPreNew:
id:#PhysXPlugin, "px_systemPreNew()"
systemPostNew:
id:#vfb_rollouts, "VFB_methods_struct.Reset()"
id:#PhysXPlugin, "px_systemPostNew()"
filePreOpen:
id:#PhysXPlugin, "px_filePreOpen()"
id:#SKAV_kill_skcg_colorcorrect_removed, "SKAV_kill_skcg_colorcorrect_removed()"
filePostOpen:
id:#PhysXPluginRagdoll, "PxRagFilePostOpen()"
id:#vfb_rollouts, "if (callbacks.notificationParam() !=2) do VFB_methods_struct.Reset()"
id:#PhysXPlugin, "px_filePostOpen()"
id:#SKAV_fix_HDRI_FilePostOpen, "SKAV_correct_HDRIAddon()"
id:#SKAV_NormalBump2VrayNormal, "SKAV_NormalBump2VrayNormal()"
id:#SKAV_setupMax_filePostOpen, "SKAV_setupMax()"
filePreSave:
id:#PhysXPlugin, "px_filePreSave()"
id:#SKAV_backupsave, "backupSave()"
selectionSetChanged:
id:#PhysXPlugin, "px_selectionChangedDirty()"
preRender:
id:#AvizstudioToolsATilesPreRender, "ATilesOnRenderSetup 1"
postRender:
id:#AvizstudioToolsATilesPostRender, "ATilesOnRenderSetup 2"
sceneNodeAdded:
id:#PhsyXPlugin, "px_syncRagdollList()"
preSystemShutdown:
id:#CATUtils, "CAT_OnMaxShutdown()"
id:#PhysXPlugin, "px_systemPreShutdown()"
sceneUndo:
id:#PhysXToolPanel, "PxPanelUndo()"
sceneRedo:
id:#PhysXToolPanel, "PxPanelUndo()"
preModifierAdded:
id:#PhysXModRB, "PxModRBPreAdded()"
id:#ApexClothingModifier, "PxApexModifierPreAdded()"
id:#MassFXClothModifier, "PxClothModifierPreAdded()"
postModifierAdded:
id:#PhysXModRB, "PxModRBPostAdded()"
id:#ApexClothingModifier, "PxApexModifierPostAdded()"
id:#MassFXClothModifier, "PxClothModifierPostAdded()"
preModifierDeleted:
id:#PhysXModRB, "PxModRBPreDelete()"
id:#ApexClothingModifier, "PxApexModifierPreDelete()"
id:#MassFXClothModifier, "PxClothModifierPreDelete()"
postNodesCloned:
id:#PhysXModRB, "PxModRBCloneHappend()"
id:#SKAV_inherit_boxmode, "SKAV_inherit_boxmode()"
postRendererChange:
id:#vfb_rollouts, "VFB_methods.VFB_ResetRollouts()"
nodeCloned:
id:#SKAV_uniqueVisibiltyController, "uniqueVisibiltyController()"
preNodeBonePropChanged:
id:#PhysXPlugin, "px_stopSimulationForEditing()"
preNodeGeneralPropChanged:
id:#PhysXPlugin, "px_stopSimulationForEditing()"
tabbedDialogCreated:
id:#SKAV_MaxfilenamePlusCameraname2Renderoutput_tabbedDialogCreated, "MaxfilenamePlusCameraname2Renderoutput()"
preImageViewerDisplay:
id:#vfb_rollouts, "VFB_methods.VFB_AddRollouts (callbacks.notificationParam())"
postImageViewerDisplay:
id:#SKAV_openVRayFB_postImageViewerDisplay, "SKAV_openVRayFB()"
As i mentioned before, i got crashes during saving (even autosave or automated savings from VRay creating the files for distributed rendering) and when i select one of the actual FP object.
-
Comparing your callbacks with mine, these are the extra events related with save and render processes:
filePreOpen:
id:#SKAV_kill_skcg_colorcorrect_removed, "SKAV_kill_skcg_colorcorrect_removed()"
filePostOpen:
id:#SKAV_fix_HDRI_FilePostOpen, "SKAV_correct_HDRIAddon()"
id:#SKAV_NormalBump2VrayNormal, "SKAV_NormalBump2VrayNormal()"
id:#SKAV_setupMax_filePostOpen, "SKAV_setupMax()"
filePreSave:
id:#SKAV_backupsave, "backupSave()"
preRender:
id:#AvizstudioToolsATilesPreRender, "ATilesOnRenderSetup 1"
postRender:
id:#AvizstudioToolsATilesPostRender, "ATilesOnRenderSetup 2"
Without knowing what does each one, i don't see other way to identify what is causing the conflict, that by trial and error, removing scripts one by one.
Also take in account these are only the Maxscript callbacks. Compiled plugins use their own events, which are not visible here.
-
You are right, these are our own callbacks and 2 more from an external scripted geometry plugin.
Cause we are using scripts so heavy, i wrote a script disable all these and clean a scene from all callbacks.
To give it away on externals or render on farms.
I cleaned some some files that using FP, but max keeps crashing.
I even removed all persistant variables without help.
As you sugessed i tried opening a crashing maxfile the on another machine and it instant crashes too, after selecting the FP objects.
I'll zip that file and send it to you.
One thing i find out is. When have the controlpanel CLOSED, selecting the FP object does not crash the max.
Even when the controlpanel gets enabled than, but is in create mode. The max does not crash.
But when switching the controlpanel to modify mode, it instantly crashes.
Seems to me that it has something to do with displaying the gui pictures.
-
Yes, i can see exactly where it fails: when the modify panel opens, Forest tries to load the thumbnails listed on "geometry\index.dat". But for some reason this data is corrupted and crashes, although there is not any logical reason for that, and we cannot reproduce the problem either.
Please, send me that scene and i'll check it. If we cannot find any clue, i'll prepare a custom patch with extra debug logs and send it to you.
-
As happened with the previous files, we can open the scene without problems.
I just sent you a custom Forest version by e-mail. Please, follow the instructions and send us the debug log.
Thanks.
-
I got some time to searche for the problem and finaly found it.
If you add this to a MaxScript in the Startup folder, max crashes as shown in my last posts.
Seems to me that something is stored on a layer that is declared as empty when looking for the nodecount.
So the layer and its contect gets deleted by this script.
fn deleteEmptyLayers = (
print "execute deleteEmptyLayers()"
debug = false
trennersign = "---" --internal sign to seperate layers in groups, so this layer stays in the scene even if empty
emptyLayers =#()
defaultlayer = layerManager.getLayerFromName "0"
defaultlayer.current = true
for i = 0 to layerManager.count-1 do (
ilayer = layerManager.getLayer i
layerName = ilayer.name as string
if debug then print layerName
layer = ILayerManager.getLayerObject i
layerNodes = refs.dependents layer
layer.Nodes &theNodesTemp
if theNodesTemp.count == 0 and findString layerName trennersign == undefined do (
append emptyLayers layerName
)
)
for i = 1 to emptyLayers.count do ( layermanager.deleteLayerByName emptyLayers[i] )
if LayerManager.isDialogOpen() == true then (
LayerManager.closeDialog()
layermanager.editlayerbyname ""
)
)
callbacks.addScript #filePostOpen "deleteEmptyLayers()" id:#deleteEmtyLayers_filePostOpen persistent:false
-
Ok, i can reproduce the problem. It happens because the script removes unused objects from the "forest_templates" layer, which is used to store billboard templates and library objects.
Forest also runs its own cleanup process on save, so probably there is a conflict between them.
It can be fixed excluding the forest layer in the script :
fn deleteEmptyLayers = (
print "execute deleteEmptyLayers()"
debug = false
trennersign = "---" --internal sign to seperate layers in groups, so this layer stays in the scene even if empty
emptyLayers =#()
defaultlayer = layerManager.getLayerFromName "0"
defaultlayer.current = true
for i = 0 to layerManager.count-1 do (
ilayer = layerManager.getLayer i
layerName = ilayer.name as string
if layerName != "forest_templates" then (
if debug then print layerName
layer = ILayerManager.getLayerObject i
layerNodes = refs.dependents layer
layer.Nodes &theNodesTemp
if theNodesTemp.count == 0 and findString layerName trennersign == undefined do (
append emptyLayers layerName
)
)
)
for i = 1 to emptyLayers.count do ( layermanager.deleteLayerByName emptyLayers[i] )
if LayerManager.isDialogOpen() == true then (
LayerManager.closeDialog()
layermanager.editlayerbyname ""
)
)
callbacks.addScript #filePostOpen "deleteEmptyLayers()" id:#deleteEmtyLayers_filePostOpen persistent:false
Additionally i suggest to not rename this layer, or move the objects from it. It nof, other unexpected problems would happen.
-
I changed the code exactly in that way to prevent the crashing.
I'm very glad to have that problem solved !
-
That's great! Glad we could help out. :)