Really? Gee, that’s easy to add.
I just checked support for ColorScaleAttribs to the SG in CVS, together with support for some more TextureStageBlendModes. Should be in 1.6.0.
Hey, that’s great, thanks! 
Maybe we should put some more emphasis into knocking off the rest of the unsupported state attribs too.
David
That’s wonderful, pro-rsoft, thanks! 
Aah, that’s good to hear - thank you.
As to 2, hmm… I think that for now I’ll stick with just flattening the trees beforehand, but thank you for reminding me of the asynchronous version - I may end up using that.
laughs I walked into that, I suppose!
Very well, then, I’ll try to get around to giving that a shot.
Hmm… Where is the frame rate meter code, if I may ask? If acceptable, I think that it would be beneficial for me to base my code off of that, especially as I think that it’s a potentially useful tool for others to use as well, and in the same manner as the frame rate meter.
[/quote]
The FrameRateMeter class can be found in the panda/src/grutil directory.
But really, it’s just as David said. The relevant portion of code is:
void FrameRateMeter::
do_update(Thread *current_thread) {
_last_update = _clock_object->get_frame_time(current_thread);
double frame_rate = _clock_object->get_average_frame_rate(current_thread);
double deviation = _clock_object->calc_frame_rate_deviation(current_thread);
static const size_t buffer_size = 1024;
char buffer[buffer_size];
#ifdef WIN32_VC
// Windows doesn't define snprintf(). Hope we don't overflow.
sprintf(buffer, _text_pattern.c_str(), frame_rate, deviation);
#else
snprintf(buffer, buffer_size, _text_pattern.c_str(), frame_rate, deviation);
#endif
nassertv(strlen(buffer) < buffer_size);
if (get_text() == buffer) {
// Never mind; the frame rate hasn't changed.
return;
}
set_text(buffer);
}The frame rate meter is implemented in C++, in panda/src/grutil/frameRateMeter.. It’s not at all clear to me how a live onscreen text object is similar in function to an object that dumps a statistical record, though. Maybe you mean the actual computation of the average frame rate? This is handled by the ClockObject (globalClock), in panda/src/putil/clockObject..
Or maybe you just mean the code that enables the frame rate meter? This is in Python, in direct/src/showbase/ShowBase.py, the method setFrameRateMeter() and related code.
It seems to me that the functionality you’re looking for can be handled in five to ten lines of Python code. If you’d like to make it available to everyone else, you can add it to ShowBase.py.
David
Well, I think that I had two reasons for wanting the frame rate meter:
First, the frame rate acquisition has presumably already been done there, and should be readily accessible, leaving at least a (perhaps very) little bit of duplication of effort that might be avoided.
Second, and, I daresay, answered in your response, drwr, I was hoping to make it as simple to use as is the frame rate meter - just request it in config.prc, and receive output at the end - and so wanted the code to “hook it into” a Panda program (my apologies for any lack of knowledge on my part in this matter - I don’t think that I’ve tried it before).
Thank you both for your responses and help - it looks as though you two have given me what I’ll want.
PS: Happy New Year, all (well, midnight just passed here, at least)!
I’m now considering the means of generating my trees, and find myself again stuck. 
I’ve considered a few options:
1) Procedural generation based on a “skeleton”:
A “stick-figure” tree shape is generated, and from that vertices are calculated and leaves generated.
Pros:
- May produce a large variety of trees, with little repetition.
Cons:
- Probably has the longest development time amongst the option here, I would guess.
- Getting the texture maps to branches to fit nicely with their parents might be tricky.
- Optimising the models (primarily, I think, the flattenStrong method) might be an issue, if I attempt to do this at run-time, to create and destroy trees on the fly as the player moves about the forest.
As to using the asynchronous version of flattenStrong, would that be advisable if I were attempting to do so for a number of trees at a given time - as I think might be generated while walking through a forest?
Note: It has been suggested to me that I do more or less the above, but on the GPU, in a shader.
It was also suggested, as I recall, that I do something akin to a combination of this and the below, generating VBOs containing tree parts that are re-used.
Does anyone have any input on any of this?
2) Semi-procedural generation, using pre-defined tree parts.
Various parts of trees - trunks, branches, etc. - are mixed-and-matched to create a variety of trees.
Pros:
- Simpler than the above
Cons:
- Texture matching at branch bases is unlikely to look good, it seems to me.
- Likely to lack internal variety (within a given tree, that is), I suspect.
3) 3D Modelling
Pros:
- Straight-forward.
- Texturing should, I think, be easier to match up than in either of the above.
Cons:
- The number of individual tree templates would presumably be limited.
(I may have missed some items in the pro- and con- sections above; I am tired tonight, I’m afraid.)
What I’m asking for, then, is advice on this choice, including any further suggestions that anyone might have.
Of course, if someone knows of a third-party tool that might help me - an actual tree generator especially - then please do let me know. In this case the technology is a means to an end to me, with the game itself being my goal. Buying a piece of technology, while not entirely out of the question, might be mildly problematic for me at the moment, especially as the exchange rate is not likely to be in my favour, I don’t believe.
In my honest opinion, I think that you’re setting your standards way too high for a game. Is it really necessary to procedurally generate every single tree, using geometry for every single leaf?
In a lot of games, there could be many characters in a level that look identical to each other, but nobody who plays the game really cares. So why not do something similar with your trees?
Create just a few tree models and reuse them as needed, perhaps using different sizes and rotations to create some variety. It might also help if you strategically arrange your level to limit what the player can see at any given time.
It is your game, of course. That’s just the way that I would try to do it.
I believe that I understand your point, T Rex, but the game that I have in mind is one that centres around exploration, and for which I want an environment that can be beautiful when appropriate, and atmospheric and interesting in general.
For nearby trees, I do very much want individual leaves (or at least leaf clusters; at least some trees seem to put out clusters of small leaves close together that should look fine modelled in that manner) - it looks a lot better when seen at close range, I find.
Note, of course, that this doesn’t translate to always using leaf- or leaf-cluster- level geometry - after all, one might well not notice the lack of it at range… 
(It also probably helps that I intend to stylise my trees in rough proportion to their distance - that is, I intend that distant trees be stylised, while nearby ones be realistic.)
Unfortunately, I’m aiming to allow the player to wander fairly freely, so strategic arrangement would likely be rather problematic.
You’re right in saying that I am setting my standards high - but I honestly don’t think that they’re too high for a game, as such. Why should a game not have high standards, after all?
It seems to me that this depends on the game - a game in which individual characters are generally important (a classic adventure game, for example) might be harmed by clone characters, while an action game, in which said characters may be little more than walking obstacles, and no one has much value for the player (perhaps aside from a point-value).
I might end up using a limited set of tree models, but I’d really rather not, I feel… 
Thank you, however - I appreciate your point, I believe.
First of all, I just wanted to say that this sound really neat, and I would love to see any progress posted here! I especially like the distance stylizing, which is similar to a part of the game I’m rind of ramping up to work on - though not quite as dynamic as yours.
Overall, I feel that option 2 would be best. It’s true the texture issue would take some trial and error, but depending on how realistic you want to go, a well-made tileable texture could easily pass between objects. Personally, I wouldn’t go for a photorealistic texture if you’re going from stylized trees; a variance is nice, but polar opposites would probably just look out of place. Things that would require a non-standard texture like a knot or stump could be their own objects, attached separately.
Seeing as how important this aspect of the game is, it may even be worthwhile to create an algorithm for choosing a texture based on the object it’s attached to and that object’s texture? I’ve never done something like that, so please forgive me if it sounds ridiculous.
Good luck!
Thank you very much!
Once I (hopefully) have something worth showing, I will hopefully indeed post it here.
Possibly, although I’m not convinced. The effect that I’m hoping, I think, for is a place that seems real and solid at close range, but becomes somewhat etherial and (well, more) otherworldly at range. This is, however, something that, once achieved, can be tested and adjusted as called for, I think.
Hmm… Come to think if it, you’ve sparked a thought: might I not get away with specifying appropriate general texture coordinates for the branch base, with a particular reference point, and then simply offset them by an amount calculated from the position along the parent trunk? At the least, that seems as though it should help…
Hmm… Would you elaborate, please? I’m not quite sure of what you’re describing, I’m afraid…
Thank you very much for all of your comments!
I suppose it depends on how you’re attaching the pieces. You mention a “parent trunk” in your last post, so I assume it is in a way that you can retrieve the other parts of the tree that branches are attached to. In this way, if you attached a branch to a trunk, set a variable for that trunk, got its texture, and applied the branch texture based on the trunk’s texture, you could keep the texture transition as seamless as possible. Have different branch and trunk textures that match up with one another, like texturing in pairs, and maybe have a couple of different options for each set.
I don’t know if I’m explaining this properly, or if it’s possible to do it exactly in the way I’m thinking, but the important thing is that if you matched up the textures ahead of time, and made sure they were paired up correctly, it could work just as if you textured the tree as a whole.
Hmm… Perhaps I’m misunderstanding you.
I don’t see a way of having the textures match up (that is, not show discontinuity) simply by selection of textures, given no predetermined position on the parent branch. Surely, presuming that a pattern of some sort exists on the parent branch’s texture, arbitrary placement of a child branch could easily result in a visible discontinuity between them?
As it happens, I’d probably simply use the same texture for both the parent and the child. What I’d want to do would, I think, be to adjust the texture coordinates of the child so that they match those that should be found at the matching positions of the parent… Hmm… Which might actually work with a tree assembled from parts…
I do also worry about whether such objects would be likely to render quickly, however, without flattening. If I do decide to flatten on the fly, it seems to me that I might as well keep looking - for now, at least - for full procedural generation resources (specifically, if available, a third-party generator)…