I am using Forest Pack pro with 3DSMax 2017 (thus indigoMAX 0.5.0),
The forest is used to generate grass with about 200 000 objects.
If I render directly the scene, it crashes indigo. Digging into the issue I noticed that the exported objects are duplicated and not instantiated.
If I instantiate from FPP the exporter works fine but 3Ds Max suffers a lot.
I tried the same scene with MAX 2015 and the exporter shipped with indigo 3.8, no issue there.
Does other have this issue ? did I missed a configuration somewhere ?
3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
-
- Posts: 2
- Joined: Fri Jan 03, 2014 2:25 am
Re: 3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
You have to much objects in your scene, you need to Instanciate with a decent aera map and well scattering. Then you can export the grass then include it in the master file for more clarity.
The real trick is to create a model of an instanciation of something larger than a few grass blades. Like a circles of grass of 60cm, 90cm, 10cm....
Then populate your aera with those new database of models.
It mean, have less geometries to charge in RAM, through 3ds max even Indigo.
The real trick is to create a model of an instanciation of something larger than a few grass blades. Like a circles of grass of 60cm, 90cm, 10cm....
Then populate your aera with those new database of models.
It mean, have less geometries to charge in RAM, through 3ds max even Indigo.
errare humanum est
-
- Posts: 2
- Joined: Fri Jan 03, 2014 2:25 am
Re: 3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
Hello
Sorry for the lack of explanation. In fact there is a regression, the previous exporter was catching object well from within Forest Pack and I had scenes with this many objects running well.
The issue with the new exporter is that it does not understand the fact that the FPP objects are instances of the same object.
I have made a small scene to illustrate this. If I export the forest directly I get code like
Same mesh files but several mesh meaning indigo will load several times (also the coordinates are wrong see below)
If I ask FPP to instanciate the objects (and Max can struggle in this case) the exporter give me the correct code :
The material is also not well captured.
Is there a way to fix the indigo 4 exporter. Today I have to go back to MAX 2015 with the former exporter installed, which is both a licencing issue and can also cause file transfer issues. Instancing is not really an option given the number of objects.
I have attached a test scene with a very simple forest and the exports.
Thank you
Brice
Sorry for the lack of explanation. In fact there is a regression, the previous exporter was catching object well from within Forest Pack and I had scenes with this many objects running well.
The issue with the new exporter is that it does not understand the fact that the FPP objects are instances of the same object.
I have made a small scene to illustrate this. If I export the forest directly I get code like
Code: Select all
<mesh>
<uid>9</uid>
<name>Box001_mesh</name>
<normal_smoothing>false</normal_smoothing>
<subdivide_pixel_threshold>4</subdivide_pixel_threshold>
<view_dependent_subdivision>true</view_dependent_subdivision>
<external>
<path>ExportInsideFPP_meshes\mesh_7739751086920045193.igmesh</path>
</external>
</mesh>
<model2>
<uid>11</uid>
<name>Box001_model_0001</name>
<geometry_uid>12</geometry_uid>
<pos>2.0319999865888003 -1.0159999932944002 0</pos>
<materials>
<uid>13</uid>
</materials>
</model2>
<mesh>
<uid>12</uid>
<name>Box001_mesh_0001</name>
<normal_smoothing>false</normal_smoothing>
<subdivide_pixel_threshold>4</subdivide_pixel_threshold>
<view_dependent_subdivision>true</view_dependent_subdivision>
<external>
<path>ExportInsideFPP_meshes\mesh_7739751086920045193.igmesh</path>
</external>
</mesh>
<model2>
<uid>14</uid>
<name>Box001_model_0002</name>
<geometry_uid>15</geometry_uid>
<pos>-3.0479999798832003 -0.5079999966472001 0</pos>
<materials>
<uid>16</uid>
</materials>
</model2>
If I ask FPP to instanciate the objects (and Max can struggle in this case) the exporter give me the correct code :
Code: Select all
<mesh>
<uid>9</uid>
<name>Forest001_Box001_0_mesh</name>
<subdivide_pixel_threshold>4</subdivide_pixel_threshold>
<view_dependent_subdivision>true</view_dependent_subdivision>
<external>
<path>ExportOutsideFPP_meshes\mesh_7696769079597006430.igmesh</path>
</external>
</mesh>
<model2>
<uid>10</uid>
<name>Forest001_Box001_1</name>
<geometry_uid>9</geometry_uid>
<pos>1.7317043647914545 -1.0347684212100794 0</pos>
<materials>
<uid>7</uid>
</materials>
</model2>
<model2>
<uid>11</uid>
<name>Forest001_Box001_2</name>
<geometry_uid>9</geometry_uid>
<pos>-3.348295601680546 -0.5267684245628792 0</pos>
<materials>
<uid>7</uid>
</materials>
</model2>
Is there a way to fix the indigo 4 exporter. Today I have to go back to MAX 2015 with the former exporter installed, which is both a licencing issue and can also cause file transfer issues. Instancing is not really an option given the number of objects.
I have attached a test scene with a very simple forest and the exports.
Thank you
Brice
- Attachments
-
- simple FPP scene.zip
- 3Ds max test scene
- (87.62 KiB) Downloaded 272 times
-
- ExportInsideFPP.pigs
- Export from Forest Pack PRo
- (3.2 KiB) Downloaded 292 times
-
- ExportOutsideFPP.pigs
- Export after FPP instanciation
- (2.77 KiB) Downloaded 284 times
Re: 3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
FYI, I've produced something like that once.
I used Notepad++ to search and replace by regular expression to change all mesh ids.
So, basically, I kept just 1 mesh and in all the "model2" I changed the uid accordingly to this mesh.
This is not very stylish and could take some time when you handle huge xml / igs files because of the iteration number, but it does the job.
... and honestly I kept 3 mesh to get a certain variation but was not the purpose to have a reproducible workflow.
I used Notepad++ to search and replace by regular expression to change all mesh ids.
So, basically, I kept just 1 mesh and in all the "model2" I changed the uid accordingly to this mesh.
This is not very stylish and could take some time when you handle huge xml / igs files because of the iteration number, but it does the job.
... and honestly I kept 3 mesh to get a certain variation but was not the purpose to have a reproducible workflow.
errare humanum est
Re: 3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
Hi guys, I noticed this issue as well while looking at one of Jay-ko's scenes.
The way Indigo (until now) does instancing, is that different model nodes are supposed to refer to the same mesh nodes. Indigo didn't handle the case where each model has its own mesh node, even if the mesh nodes refer to the same .igmesh on disk.
I've added some code for the next 4.x build, so that meshes are only loaded into memory once if they come from the same path on disk, even if they are loaded by different mesh nodes.
This takes the memory usage from something like 30GB+ to ~5GB on one of your scenes Jay-ko
(This is probably something that should be improved in the 3ds max exporter as well.)
The way Indigo (until now) does instancing, is that different model nodes are supposed to refer to the same mesh nodes. Indigo didn't handle the case where each model has its own mesh node, even if the mesh nodes refer to the same .igmesh on disk.
I've added some code for the next 4.x build, so that meshes are only loaded into memory once if they come from the same path on disk, even if they are loaded by different mesh nodes.
This takes the memory usage from something like 30GB+ to ~5GB on one of your scenes Jay-ko
(This is probably something that should be improved in the 3ds max exporter as well.)
Re: 3Ds Max 2017, indigo max 0.5.0 and Forest Pack Pro
huhuhu
It's a good news thanks!
It's a good news thanks!
errare humanum est
Who is online
Users browsing this forum: No registered users and 3 guests