[Closed] getRadiosityMesh
Has anyone used this from maxscript?
radiosityMeshOps.getRadiosityMesh $
I tried to get the radiosity mesh generated from the solution, because it can not be collapsed, it could be great this option can be done, because Blender actually does it, you generate the radiosity and if you want to generate the solution as a new mesh or even replace your objects then you can do it, but in Max you can’t, and this mesh actually is there somewhere but if I use the previous maxscript from the MAXScript mini-lister and the only response I get is TriMesh, but my object is still the same, why?
Thank you!
Darth Gefallen.
Ok, I think I’m getting to understand this. The Method getRadiosityMesh only saves in memory a TriMesh of the node selected. I came to this conclusion ‘cus if I use getNumFaces it returns the number of faces from the selected node, so if I do this:
getNumFaces $
and I have a box selected with 8 vertex it will only return it has 12 faces. But if I type this:
getNumFaces (radiosityMeshOps.getRadiosityMesh $)
it returns 389 faces, the number of faces that my radiosity mesh has. So if this can be possible, then maybe I will need to create a new mesh and then get the index of vertex or something like that to get the mesh and us it to anything I want. I’m new in this so I’m sorry if maybe I sound a little crazy, hehe, my apologies.
This is not entirely correct.
If you process the Radiosity and subdivide your object, the radiosity mesh should return alot more faces than the original.
The TriMesh value is a Mesh containing triangular faces just like the Editable Mesh does. It is the internal representation of mesh geometry.
You can grab the TriMesh value returned by the radiosityMeshOps.getRadiosityMesh() method and put it into an Editable Mesh’s .mesh property.
For example,
*Create a box
*Add Normal modifier to invert the normals
*Place a Free Point Photometric light inside
*Process Radiosity
Call
newMesh = copy $Box01
convertToMesh newMesh
newMesh.mesh = radiosityMeshOps.getRadiosityMesh $Box01
newMesh.scale = [1,1,1]*39.3701
The reason for the multiplication of the scale is that Radiosity works in World Scale and in Meters. Since 100.0 cm / 2.54 = 39.3701, you have to scale up if your scene is set to Inches. Otherwise the Rad. mesh will appear much smaller than the original.
Hey sorta on the same topic, the radiosity mesh is loaded into memory, i notice that max is ALOT faster to use, is there a way to do something similar with the click of a button, load the scene mesh into memory so I can preview faster?
Also is there a way to make my own “Assign Vertex Color” script for the radiosity, as the max one doesnt work with the following…
callbacks.addScript #radiosityProcessDone "fnDoSomething()" id:#radiosityDone
fn fnDoSomething =
(
callbacks.removeScripts #radiosityProcessDone id:#radiosityDone
select $Teapot01
mySelection = getcurrentselection()
AssignVertexColors.ApplyNodes $ -- crashes on this line here! buy why?!
)
The TriMesh value from the Radiosity calculations ALREADY CONTAINS the vertex colors! So if you run my code above and then check Show Vertex Colors, the new mesh should looks just like the original illuminationwise…
So there is no need to assign any vertex colors when using the radiosityMeshOps.getRadiosityMesh() method.
Thank you both for the answer!!!
Thanks master Bobo. So then, I was thinking on get the entire mesh as indexed vertex when there is a simple process. Thank you! This forum is really full of masters, but that’s nothing, the important of CG Society is that every body else shares their own researchs, doubts and questions.
Gibbz,
I ran the Bobo’s code and it worked. You just need to add a VertexPaint modifier to the new mesh, select Vertex Color Display from the Vertex Color Display Controls and that’s all.
The only thing that every body need to do is: to generate new code to select or get a selection, add it to a list and then get their meshes or anything one needs to. This is really a good advance to Max, it allows to customize your tools as you want to. I’m sorry, MAXScript is awsome!!
okay so ive been going about assigning vertex colors wrong? Instead of assigning them to my original mesh, i should apply the vertex colors to the radiosity tri mesh, and then this becomes my new mesh?
Ill have a little mess with it tonight, see if Im understanding it right
EDIT: ok i see whats happening now… is there something simmilar to .mesh but for editable poly, or should i just convert my mesh to editable poly after its done?
Cheers!
You can read .mesh from any geometry incl. EPoly, but you can assign to it only if it is an EditableMesh. So you can collapse your object to EMesh and assign the radiosity result to it. Then you can convert back to EPoly if you want, but since you are hardly going to edit it, it would be pointless and approx. 4 times slower to display in the viewports anyway…
Is editable poly 4x slower than editable mesh to display? Is there any reason for this? Or somewhere where i can find more info on it.
Thanks
More or less. The internal data structures of EPoly do not translate directly to the format graphics card love to display fast. So in general, adding a MeshSelect on top of the stack makes panning and orbiting around EPoly objects several times faster (because the top of the stack returns a TriMesh and it is not reevaluated unless the modifiers below are animated).
So for skinned characters it does not help much since the deformations invalidate the stack constantly if you are playing back, but for statci objects it is much faster to have MeshSelect or TurnToMesh on top.
This is also one of the reasons Turbosmooth is faster – not only does the subdivision work faster, it was also designed to input EPoly and output TriMesh, thus adding it on top of the stack already speeds up orbiting, panning and zooming on a static frame…