Transluceny works differently from any other part of the Poser shader system. Specifically contrary to the general "downstream only" model of the shading system, connecting things to the translucency channel creates "up-stream" effect.

The channel itself is identical to the ambient channel, but diffuse lighting nodes (diffuse, clay, skin etc.) connected to the translucency channel act as if the normals of the surface are reversed, so that lights behind the surface cause it to be illuminated. 

A few things to note:

i) The diffuse nodes need to be exclusively attached to the translucency channel. If they are part of a tree that attaches to any other channel (e.g. Ambient) the effect is nullified. 

I presume that the direction of the diffuse normals for the specific node are determined at some time before the sampling for the entire Poser surface is carried out and the reversed state of the normals is marked as a flag on the node data object.

ii) In P6 and P7 (?) (but not P5) the "normals forward" checkbox of the diffuse node must be checked (it also works with other diffuse type nodes if they have this checkbox).

iii) When using shadows the shadow bias must be great enough for backlights to penetrate a solid object far enough to illuminate the front (camera facing) surface. i.e. if an object is too thick the front of an object won't get illuminated. It's easy enough to demonstrate the effects of the translucency channel with shadows disabled, but tweaking it to get good effects in practise (e.g. backlit ears) can be a lot harder.

MetaForm can add an "environment prop" to the scene, which looks like a weather vane. It should be at the bottom of the panel. It has parameters for wind speed and the direction can be set by rotating it. You can also turn the gravity off if you don't want the fire to be rising vertically.

The other method of doing this is to move the plane between the first and last (rendered) frame. Both methods probably require increasing the particle rate.

The latest version BTW is v1.11 which you should be able to get from your account page at DAZ.

The power of two thing for texture sizes doesn't hold true nowerdays. About ten years ago it was beneficial to use powers of two because processors and therefore applications could calculate row positions faster, but modern processors really don't see a benefit and most access to images need to go through various API levels and/or use precalculated lists of row addresses. On the other hand, it may beneficial when reducing texture sizes to do so by 1/2 posers, i.e. 50%, 25% etc. reduction. Thats because most resampling/filtering calculations do give better results when they applied at actaula pixel boundaries. Bill

You may want to try feeding a single colour to the Gradient Bump channel of the Poser surface. Logically, for shading the Gradient Bump changes the apparent normal of the surface at that point. So far as I can remember this also applies to generated reflected and refracted rays. The Bump Map channel does does the same too, but calculates the normal change from the pixels in the map, so a uniform colour would give you a zero gradient. Bill

P5 can do negative lights too if you attach a negative node to the intensity in the Material room.

I've never checked with P6, the last bit of deep investigation was actually P5, but I'm interested myself in finding out whther the problem still exists so I'll try a test harness this weekend. The bugs were crashes due to unitialised data in Actor.SetGeometry(). It was fixable at low level but a reasonable workaround was to load the geometry externally using pose files. From what I could remember the memory leaks were still a problem. Bill

MetaForm at DAZ does much the same as RealFlow. You cannot practically use Python for geometry creation since there are some serious bugs in creating new geometries as well as some very large memory leaks in that part of the interface. Bill

No but the 3DS format can contain parametric objects as well as meshes. If these were exported from another application, Bryce may have translated them directly without them ever being represented as meshes in either program. Converting parametrics between programs is relatively simple, as is converting parametrics to meshes, so long as boolean operations are not involved. Bill

Some of the beam parts certainly look like Bryce primitive cubes, judging by the wireframes. It's possible that even if it was modelled in an external program, that primitives may been exported in a file format that supports parametrics (e.g. 3DS) and then converted directly into Bryce primitives on import, without ever going through a mesh conversion operation. Bill

According to the manual the E button is visible with lights heightfields, lattices, stones and imported meshes, i.e. it brings up the edit menu for any objects that have a general 'Editable' characteristics. Where this differs from the 'A'ttributes menu option seems fairly arbitrary. As I said though its possible that mesh objects may need to be ungrouped before they can be exported. It may be that the "imported mesh" status is somehow lost if the objects are saved then reloaded, although that would seem a bit peculiar. Bill

The 'E' button being one of the little icons in the column ('E' stands for 'Edit'?) next to the object when it is selected in the Bryce display window (along with the 'M' material editor. As far as I remember this brings a dialog with smoothing options, but at that point the Ctrl-D should initiate export for meshes as well. I suspect that models that are constructed for groups of meshes would need to be ungrouped and exported in parts. Still a million miles from a machine with Bryce installed so I still can't verify, this is just off the top of my head. Bill

Actually in Bryce 5 (and 4 possibly) it should be possible to export mesh objects if you load the file into bryce and use the E button/Ctrl-D. This should apply to all mesh objects. ... at least according to the manual ;-) I think I have verified this before, but I'd need to check to be sure. Nevertheless if the object won't export, it's still likely to be connstructed from primitives in Bryce. Quite a few complex models actually are. Bill

Actually extracting data from Bryce files is fairly easy, the problem however is that it gives youi very little to actually work with. To understand this, its important to understand that Bryce is primarily a raytracer rendering engine, similar to PovRay except with a GUI rather than a SDL. Although Bryce and PovRay have facilities to import mesh objects, most Bryce models are constructed from boolean operations on primitive parametric shapes. Bryce never actually creates or stores the final constructed object in memory, what you see in the render is effectively an illusion that's created during the rendering process by calculating the points at the which the rays enter and leave various positive and negative objects. Therefore what you get from obp files and other Bryce formats is just a list of the primitive cubes, squares, cones etc. and their locations, boolean polarity, grouping etc. In order to create a physical mesh object from this information you would then have to effectively create the core of a full CSG modelling application, which is maybe 100 times more work that the simple file data extraction. The question then is why would you want constrain this code solely to the fairly small and static Bryce market when you could instead slap your own simple interface on it and sell it as an application independent modeller. Another major disadvantages about developing a Bryce (or any application)-only exporter is that you are constrained by the functionlity of Bryce itself. Even if there are more things that your modelling core can do, theres no point in implementing them as the Bryce exports will never support them and, if there are things that Bryce exports that are difficult to implement or pointless, omitting them still creates an apparent weakness in the product. Also important for Bryce modelling and export is the procedural texturing. Although its possible, to a degree, to emulate the procedurals from the information in the files in practical terms you would really need direct access to the sampling procedures in the raytracer itself in order to satisfy the requirements for a well featured export. For an application independent modeller, this isn't really an issue. Texturing can simply be left as an area that's not covered in the spec. Sometime last year my company approached DAZ with a view to possibly implementing our existing code as an exporter for Bryce, we had most of the elements for the CSG and isosurface operations and a solution for mapping onto an arbitrary CSG constructed topological surface without the problems associated with standard projections, so long as we could access the raytracer sampling. At the time we were told that the exporter work was nearly completed anyway. So maybe the next version will have a more advanced export options. Bill

As I've said before I'm dead set against calls for a 64 bit port. A well written 32 bit application should be more than capable of handling dozens or hundreds of high res figures and any effort that EF could expend in porting to a 64 bit system would be much better spent in redesigning the existing core. Bill

Decompilation of the code is actually breach of licence and doing so will get you into a lot of trouble. I also have serious doubts about whether it's actually any more efficient than other legitimate application modification techniques. In any case it's certainly not necessary, but, as I said, the practical aspects of adding new nodes at least for the general user base outside a dedicated studio are probably insurmountable. Bill