[Closed] Max script help, exporting vert.z data

theObj = $object_01 --don't need to select!
    tmesh = snapshotAsMesh theObj --grab the TriMesh
    num_verts = tmesh.numverts --get the number of vertices
    for v = 1 to num_verts do --loop through the vertices
    format "%," (bit.IntAsHex (getVert tmesh v).z ) to:out_file --output the Z value
    --clearSelection() --you do not need this
delete tmesh --once done, delete the TriMesh from memory
  

You don’t need to select an object in order to access its data. In fact, you can access and export even objects that are not visible (frozen and/or hidden). You only need to select objects AND show them in the Modify panel when operating on certain modifiers like Unwrap that require focus.

Of course, converting your Z axis to Integer means throwing away a lot of data, but if you want to export as HEX, you need the value as integer (it happens implicitly though).

Thank you for the reply Bobo!

I think I tried something very similar at about 10am this morning, I didn’t think I could nest things like that and get away with it.

Shows my lack of syntax understanding with Maxscript

I think I’m going to have to ignore what I already know about programming and start again a little, it seems quite flexible in MaxScript!

Dave

Right, well I got the exporter doing exactly what I wanted, making it upto 16 bits by appending zero’s then putting the 2nd read 8bit block in first (first in last out).

All working wonderfully, ascii formated hex that will copy/paste into a hex editor

out_name = ((GetDir #export)+”/mesh01.dat”)

out_file = createfile out_name

theObj = $mesh01 –don’t need to select!

 tMesh = snapshotAsMesh theObj --grab the TriMesh
 
 num_verts = tMesh.numverts --get the number of vertices
 
 
 for v = 1 to num_verts do --loop through the vertices
 (
 
     sVarHex = (bit.IntAsHex (getVert tmesh v).z )
     iVarHexStringLength = sVarHex.count
     sVarHexZeroToAppend = 4 - iVarHexStringLength
     
     sVarHexAppend = sVarHex
     
     for i = 1 to sVarHexZeroToAppend do
     (
         sVarHexAppend = append "0" sVarHexAppend
     )
     
     sVarHexData = (substring sVarHexAppend 3 2) + " " + (substring sVarHexAppend 1 2)
     
     format "% " sVarHexData to:out_file
 )

delete tmesh –once done, delete the TriMesh from memory

But, just wondering how far I can go with this. MaxScript has some really nice functionality with strings and insertion ( <string>replace <string> <from_integer> <length_integer> <new_string> ), so in theory I could do this outside of a hex editor and macro scripts in other software.
Is there any limit to the string sizes I have in MaxScript? Would over say half a meg of ascii be too much?

Right now I can bring ascii into MaxScript, but ideally I need to work in Hex (as that is what I output to). Is it possible to do any hex > ascii or ascii > hex operations within MaxScript with BIG strings?

I’m guessing this step is a complex next one to make, so I’m happy if I just work outside Max as I planned, but if it’s possible I may well give it a shot. Has anyone written a MaxScript ascii – hex converter that is freely available?

Thanks for any help

Dave

Take a look at the “Interface: MemStream” topic in the MAXScript Reference – it was designed to handle text file parsing in memory. It does only the reading of data though, for saving the data back you would still use regular filestream operations.

Another thing to mention – the MAXScript Heap Size is set to 7.5 MB by default. This comes from Max 2.0 days back in 1997. On modern machines, setting it to something like 64MB is no problem at all as we have GBs of RAM. It might increase automatically in the latest versions of Max if you start running out of memory, but it is a better idea to set it to 64MB once in Customize>Preferences>MAXScript, then restart Max and forget about memory problems…
It can also be tested and increased via MAXScript in the beginning of your script.

So I would expect that the handling MBs of strings would be possible.

Ah, upped the limit now. 7.5meg was probably ok for my files, but I guess raising it can’t do any harm. My files are between 256k ~ 1.5meg and the new strings are only around 512 bytes long, so not a huge amount of data. I’m glad MaxScript appears to be able to handle these happily

Seems like I go (simplified)

[b]memStreamMgr.openFile()

[/b]<string>[b]readChar/b

bit.IntAsHex (bit.charAsInt readChar)

[size=2][color=White]And that gets me my ascii string as a pure hex string in memory.

Then I can append the data I generate in the other script where it needs to go.

[/color][/size][size=2][color=White][size=1][color=Silver][color=Lime][color=White][size=2]So now getting back to hex, just unsure of the hex > dec step before I run bit.intAsChar <integer>
[/color][/color][/size][/color][/size][/color][/size][size=2][color=White]
[size=1][color=Silver]bit.IntAsHex (bit.charAsInt “a”)
[color=Lime]– returns 61

– hex > dec “61” > 97 ??

[color=Silver]str = “\x61” [color=Lime]– works but not sure how I run \x against an integer variable[/color]
[/color]

bit.intAsChar 97
– returns a
[color=White][size=2]

Looks like I need to read a little more and start making this work Seems quite possible now!

Thanks for the help again Bobo, it is very much appreciated!

Dave
[/color][/color][/size][/color][/size][/color][/size]

theVal = bit.IntAsHex (bit.charAsInt “a”)
–>“61”
str = execute (“”\x” + theVal+ “””)
–>“a”

Ah yes, I spotted that in the help (next section down :)) right after I posted, and became a little baffled by the syntax (opening and closing the string made sense “”, but having the expression wrapped in more “” confused me.

Thanks for clarifying that for me (not sure why it works, but at least I know how to make it work). Now you can just tell I’m going to be having a fun weekend making this work 😮

You certainly are the MaXster of scripting thanks once again

Dave

Normally, if you type in the Listener “\x61” and press Enter, the MAXScript Parser grabs the string, finds the escape char \x and understands that the following digits and letters denote a HEX code, so it evaluates it like that.

When you want to take an existing string “61” and turn it into HEX, you have to prepend the “\x” string to it. But you also want to run the parser on it to convert the string value to the HEX value AS IF you pressed the Enter key. This is what EXECUTE() does – it takes a string and handles it as if it was entered in the Listener. But execute always works on strings, so it expects the content of the string to be something else, like numbers, MAXScript objects, Max objects and so on (for example, execute “$Box01” returns the scene object Box01 as if you typed in $Box01 in the Listener).

BUT we want the execute() to take the content of the string we are passing it as another string and not some other value type, so we need to prepend and append extra quotes using the ” excape sequence. This way, the Parser sees “”\x61″” as the input, removes the outer quotes which would be there in every case, and is left with a string to parse which turns into the character with ASCII code HEX61 or “a”.

Ah I think that makes sense now.

The MaxScript help documentation goes so far, but your post really helped to clarify the use of the sequence for me.

I’ll have to try some more string literal reading/examples myself with the \x feature and ” escape sequence , and fully understand and be able to apply them when I need them

Thank you

Dave