Sun, Jan 19, 2:21 AM CST

Renderosity Forums / Poser Technical



Welcome to the Poser Technical Forum

Forum Moderators: Staff

Poser Technical F.A.Q (Last Updated: 2024 Dec 04 2:47 am)

Welcome to the Poser Technical Forum.

Where computer nerds can Pull out their slide rules and not get laughed at. Pocket protectors are not required. ;-)

This is the place you come to ask questions and share new ideas about using the internal file structure of Poser to push the program past it's normal limits.

New users are encouraged to read the FAQ sections here and on the Poser forum before asking questions.



Checkout the Renderosity MarketPlace - Your source for digital art content!



Subject: Comments in Poser Files


_dodger ( ) posted Wed, 11 December 2002 at 7:00 PM · edited Sun, 19 January 2025 at 2:19 AM

I was recently working on a particularly complicated CR2 file -- my gravitic-and-self-lighting candelabra for my Dungeon Lighting Set, and because of the size, I threw in some perl-style comments to keep track of where I was until I got done with the file editing. Incidentally, Perl comments follow the same method as shellscript comments and OBJ comments. Well, silly me... I accidentally left the comments in (vim could strip them all with a one-liner, but I spaced it). I loaded up the file to test it and viola... the comments had no effect whatsoever. In exactly the way comments aren't supposed to. So... I tried it with a few other files, even going to far as to comment out something that was valid Poser information. It worked fine. So Poser files do support comments. # like this. Simply begin the line with a hashmark (pound sign, number sign) and you can comments your Poser files to your heart's content. As a note, my Poser syntax highlighiting file for gvim already marks thee comments as comments, because it supports Wavefront OBJects, too. So if you use my syntax file (in FreeStuff:Poser:Utilities), comments will not only work, but will show up in (by default) blue as comments should.


Little_Dragon ( ) posted Thu, 12 December 2002 at 1:45 AM

It works in Poser 5, also. Thanks, _dodger!



_dodger ( ) posted Thu, 12 December 2002 at 2:13 AM

No worries. Stormrage found an exception: The comment cannot go before the main block. That is, you apparently cannot stick a comment in at the top of the file before the outermost unnameds.


kawecki ( ) posted Thu, 12 December 2002 at 3:27 AM

Don't use # for comments, doesn't work in any place of the file, use instead // as in C.

Stupidity also evolves!


_dodger ( ) posted Thu, 12 December 2002 at 3:46 AM

'doesn't work in any place of the file' Er, um, yes it does. That's what I just said. BTW, // isn't C, it's C++ (and Javascript). /* */ is C.


kawecki ( ) posted Thu, 12 December 2002 at 4:34 AM

// is C: one line comment and /* .... */ multiline comment. Try this { etc, etc, etc v 1.00 0.75 3.141592 v 0.00 0.00 0.00 # this comment will corrupt the mesh v 0.75 0.75 2.00 etc etc etc } And this { etc, etc, etc v 1.00 0.75 3.14159264 v 0.00 0.00 0.00 // this comment works fine v 0.75 0.75 2.00 etc etc etc }

Stupidity also evolves!


_dodger ( ) posted Thu, 12 December 2002 at 4:57 AM

// doesn't work on my compiler if it's set to straight C mode. I must admit that I didn't try it inside of a set of vertex definitions for a geomCustom (I don't use internal geometry), though that seems rather odd, seeing as the syntax for geomCustom is straight OBJ syntax, and # comments are the intended commenting method in them. You're not indenting the #, are you? I haven't and don't mean to try it with the comments indented. I think an OBJ requires the # to be the first character, no spaces preceding, if I'm not mistaken, and that would be why -- I get the strong impression that a geomCustom entry Poser reads directly into an OBJ file in memory just as if it were taking it from an external OBJ. Any problems with deltas?


kawecki ( ) posted Thu, 12 December 2002 at 10:51 AM

When I first tried to edit vertex data in props I used # for commenting old values as in obj files with bad results, so I tried // for comments and it worked. Poser structure is similar to C with Begin End blocks { } and in C # is used for preprocessor instructions (#define #include etc). People use # for comments in Poser file, but I think that Poser doesn't accept it as comment and treats the line starting with # as a sintaxis error, and depending where you put this comment Poser ignores this error without any damage and in other places this error causes harm to the data. Probably in the places where you put # without any problem you can use any other strange symbol @ $ % & ?, etc with the same result, maybe a comment without # (only text) will work also at this place.

Stupidity also evolves!


kawecki ( ) posted Thu, 12 December 2002 at 11:01 AM

About // in C: I always used it for comments in C since the days of Turbo C 2.0 and it was C only not C++. I use Borland C compilers and don't like Microsoft C compilers.

Stupidity also evolves!


ScottA ( ) posted Thu, 12 December 2002 at 4:25 PM

Been there. Invented it. ;-) Check the archives.


_dodger ( ) posted Thu, 12 December 2002 at 5:40 PM

Oh, well, this is an old version of gcc. I don't use compilers much on Windows.


bloodsong ( ) posted Thu, 12 December 2002 at 6:21 PM

huh???? i thought the comment character was *. that's what i used recently in mine. although if i resave the file from in poser, it strips those lines out. does it strip out your # lines? don't confuse me!


maclean ( ) posted Thu, 12 December 2002 at 6:25 PM

You can also put comments into the materials. Jagger posted something on this along the lines of putting 'Material Copyright by Jagger' in the materials list, and he did it with comments. Don't remember how though. mac


ScottA ( ) posted Thu, 12 December 2002 at 7:02 PM

Lol. They all work bloodsong. The story goes like this: I was teaching myself VB a couple years ago and I was writting some comments in the code. I opened a piece of code that someone posted as an example and I noticed the "" was used to store comments. At the time all of it was new to me. And I was thinking about why those symbols would not get compiled. When I opened a .cr2 file; probably to answer one of your questions. I rarely go looking for things on my own unless someone asks a question. I'm perfectly happy making models and animations. 8-) And I thought to myself. "these lines in .cr2s are written similar to VB code. So on a whim... I tried using the "" to convert channels to comments. Thus causing Poser to skip over them. You have no idea how shocked I was when it worked. It was one of those cool accidents. :-) I was thrilled that I had applied coding theory to Poser files when I didn't even understand how to write code yet. As usual. I jumped on-line and told everyone about what I just found. Not so much happy that I was able to make comments inside .cr2 files. But that I had found an effortless way to remove information from .cr2 lines without running the risk of removing too much by accident. One of the firsy people to read it on the list was a guy named Dan Wilmes (sp?). Who was a programer by occupation. When he heard that Poser files responded to standard coding syntax. His interest peaked. And he developed what is now known as CR2Editor. Now up to version6 I believe. It's one of my favorite Poser community stories. Because the sharing of info discovered by accident developed into a neat trick and a cool piece of software. Later after I learned about the other syntax also used for making comments. I switched to using the "//" symbol. Because doing it that way. I didn't need to hold down my Shift key. And it was faster. Ahhh....the good ole days. :-) ScottA


_dodger ( ) posted Thu, 12 December 2002 at 8:30 PM

I have to keep these permutations in mind and update the syntax definitions.


lesbentley ( ) posted Thu, 12 December 2002 at 8:31 PM

"//" and "#" both get striped out on a resave from document to pallet. I never heard of "*" being used before, but my bet is that it gets striped out as well. Jagger's "material comment" does not get striped out. A "valueParm", and probably any other channel type, can be used to preface a permanent comment, if it is followed by matching braces: valueParm My Comment 13-12-02 { } But poser will add a lot of standard channel code when you resave to a pallet, and the channel should be put in the normal place for a channel, not in the middle of another channel.


lesbentley ( ) posted Thu, 12 December 2002 at 8:39 PM

P.S. If memory serves me right the maximum length for a comment following a channel type is 32 characters including spaces.


_dodger ( ) posted Thu, 12 December 2002 at 9:01 PM

Les: Wouldn't you have to add a hidden 1 into it to keep it from showing up as a dial if you do it that way? If I'm not mistaken, you can also make a comment simply by defining a block that has a type Poser doesn't recognise:

            Comment ERC Definitions
                {
                    The following five channels are
                    controlled by ERC in the BODY:1
                    actor above
                }

As I discovered when I accidentally de-capitalised an entire block and lost all the dials except scale, because Poser doesn't recognise, for instance, 'twisty' or 'xoffsetb', only 'twistY' and 'xOffsetB'.


lesbentley ( ) posted Thu, 12 December 2002 at 9:17 PM

Dodger, yes that's right, if you don't want to advertise, set hidden 1. I never thought of the block comment thing, and I don't think anyone else has either. That's great. Our knowledge is growing by the day, and you seem to be playing a big part in that. Keep up the good work.


_dodger ( ) posted Thu, 12 December 2002 at 9:53 PM

Hehe. I'm a hacker at heart* * Before anyone fears I'm going to erase their hard drive, steal their credit card number, or break past their refigerator's security codes and make all their beer go flat, Read This


maclean ( ) posted Fri, 13 December 2002 at 4:53 PM

"because Poser doesn't recognise, for instance, 'twisty' or 'xoffsetb', only 'twistY' and 'xOffsetB'" Hmmm.... it's probably useless to know, but I just tried an experiment after reading dodger's comment ('scuse the pun). I renamed the Xscale dial on a body part from 'scaleX xScale' to scalex xscale' and opened the figure. Sure enough.... no Xscale dial appeared. Obviously, it's easier to use the 'hidden 1' attribute, but still... you never know when bits of weird info will come in useful. mac


bloodsong ( ) posted Fri, 13 December 2002 at 5:17 PM

okay... so how does the secret magic material comment work without getting erased when you save in poser???


maclean ( ) posted Fri, 13 December 2002 at 5:34 PM

I found my copy of jaager's post. Here it is. ----------------------------------------- A library file will open with comments // or * inside the { } Poser will not keep them for me on resave. However This - added into the Materials section - will stay until manually deleted - i.e. Poser will keep it in on resave. (You cannot put comments as a texture call, it will look for a texture by that name. So, the length of the comment is determined by low long a material name can be. The neat thing is - this shows up in the materials menu in Poser. material Copyright-2002-by-Jaager { KdColor 1 1 1 1 KaColor 0 0 0 1 KsColor 0 0 0 1 TextureColor 0.8 0.8 0.8 1 NsExponent 100 tMin 0 tMax 0 tExpo 0 bumpStrength 1 ksIgnoreTexture 0 reflectThruLights 0 reflectThruKd 0 textureMap NO_MAP bumpMap NO_MAP reflectionMap NO_MAP transparencyMap NO_MAP ReflectionColor 0 0 0 1 reflectionStrength 0 } This should keep the data in more or less forever for 99% of Poser users, what with the phobia against text editing a poser file. I just checked - UVMapper strips old comments and will remove a usemtl line that has no associated facets. So this is not a way to keep comments in an OBJ file. -------------------------- I presume by the line 'This - added into the Materials section - ' he means putting your comments in between - and - ie. 2 dashes, if you follow me. LOL mac


maclean ( ) posted Fri, 13 December 2002 at 5:41 PM

I just tried it, replacing the line 'material panel' with 'material panel Copyright-2002-by-mac' What it did was add a new panel material called 'panel Copyright-2002-by-mac'. So I now have 2 panel materials, because I didn't edit the obj. But anyway, all that's doing is renaming the material. mac


_dodger ( ) posted Fri, 13 December 2002 at 11:13 PM

MacLean: The usemtl in the object or customGeom must correspond with the material name. exactly. Therefore, you should not only update the material in the poser file, but you should replace all instances of ^usemtl YourMaterialName$ -- by ^ I mean start of line and $ means end of line, BTW -- with ^usemtl YourNewMaterialName$


maclean ( ) posted Sat, 14 December 2002 at 2:18 PM

I know, dodger. That's why I can't figure out what jaager means. All he's doing is renaming a texture.... or adding an extra one, if he doesn't edit the obj. I don't get the link with comments. mac


_dodger ( ) posted Sat, 14 December 2002 at 11:41 PM

Perhaps he's using customGeom and not an object, so all changes are in the poser file? Perhaps something like:

material Materials Copyright 2002 Dodger Designs
    {
    }

Leaving a 'blank' coloured material along with the others. I dunno, though, this one kind of bothers me in that Jaager's whole copyright-notice-on-a-material is bollocks. You can copyright a figure. You can copyright a morph target usually. You can copyright most textures (however, I'd argue that you CAN'T claim copyright on, say, an even halftone, basic stripe pattern, standard tartan, or a solid colour (I think it would be absurd for me to make a 1x1 pixel red GIF and claim that I then had control over the colour red). You can certainly copyright meshes. You can even copyright some poses, even though I think the buying, selling, and attempted protecting of poses is silly. But claiming a copyright on the settings of sixteen limited range parametres -- I really don't know about that. I mean, while you can certainly copyright the reflection map on chrome, I don't think it washes that you can copyright 'chrome'. Nor do I expect it would hold up on court much of anywhere.


Jaager ( ) posted Sun, 15 December 2002 at 4:34 AM

Hello! I based my suggestion on the following: once a material block is in a library file, it stays until you delete it manually. P3 Fem has materials like shoelaces or something. Things that came from using the CasualFem figure or something. They go to the bottom of the stack - but they will never go away unless you make them. So all you need do is add this as a new block in the Materials section = material WHATEVER YOU WANT FOR A COMMENT { } in with the others When you save it back to the library in Poser, all the junk between the { } gets filled in and the block goes to the bottom of the list because Poser puts redundant material calls at the bottom, but will not purge them.


_dodger ( ) posted Sun, 15 December 2002 at 1:34 PM

As a note, if you want to be really hardcore about that, you can also add: usemtl WHATEVER YOU WANT FOR A COMMENT into the object file anywhere except right after another usemtl command and if I'm not mistaken, Poser will automatically add it back in to the menu even if someone deletes it from the CR2.


Jaager ( ) posted Sun, 15 December 2002 at 5:55 PM

Now, that would be hardcore. I had not considered that a usemtl in an OBJ file, even if it has no assigned facets, will be handled as though it did. Very useful for prop makers - maybe?


maclean ( ) posted Sun, 15 December 2002 at 6:10 PM

Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1001681

dodger, Any way to use that to order my materials exactly the way I want them? That would be cool. See other post for details. mac


_dodger ( ) posted Sun, 15 December 2002 at 8:53 PM

Replied there, and the answer, in a nutshell, was 'I think so'


KattMan ( ) posted Mon, 30 December 2002 at 2:34 PM

I've been commenting with # inside the first main block for over a year. Matter of fact My P-Wizard does it in a few cases. I'm thinking of stripping that out though. Some third party apps (like The Tailor) crash hard when finding comments, even properly formatted ones.


Privacy Notice

This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.