The method I illustrate assumes that (0, 0, 0) is the center of the object in question. Whether that’s a true assumption depends on the design of your pogram. For avatars, that’s almost always true; for terrain elements, it may or may not be. There are other scene graph operations that will translate a point other than (0, 0, 0) into a different coordinate space, if you need this. The right thing to do will depend on the precise nature of the elements in your game.
There are three ways to create a viewport. (1) Create a new DisplayRegion on the main window. (2) Use Render-to-Texture with an offscreen buffer, and apply the resulting texture to a card that you parent to render2d somewhere. (3) Parent your viewport geometry directly into the render2d somewhere, and handle the clipping yourself.
Any of these three options is acceptable for creating a game or a scene editor. There are slightly different tradeoffs for each one. The right one for you to use depends on your particular circumstances; I can’t answer that question for you.
Each camera specifies its own field of view, which has nothing to do with the size of the DisplayRegion. Geometry is clipped to the camera’s field of view. The resulting scene is then scaled to fit the DisplayRegion.
I don’t know what you’re referring to by “the z-up model”. Is this a Blender thing? I know nothing about Blender. Why don’t you load this model and look at it to see if it is the right size for your needs?
And I don’t know what you mean about importing eggs. You mean importing them into Blender? I don’t know whether there’s a converter to import egg files into Blender or not. I kind of doubt it.
Yay! I have started work on my “project” finally! I decided to start with the editable terrain, since it is - I believe the most complex part to do. I decided that I would have a CollisionNode with a CollisionSphere parented to the GeomNode representing the terrain mesh. My idea is to relate each vertex to a single Handle, that will cause the vertex to move along with it as it moves. But after looking through the manual, I realized that using VertexData probably wouldn’t help, since I don’t believe there is a way to see whether 2 GeomNodes share the same VertexData, and at the same time, at the same time relating the Geoms to the respective vertices. Besides, the existence of more than one GeomNode might make the whole point of getting vertices quite pointless as they would be relatively, rather than absolutely, positioned.
Therefore, I have decided to go for the option of accessing EggData directly. However, it appears that the documentation provided for the EGG API is skewered toward writing EGG Files, Whereas I need to read and access them on a constant basis. (Real-Time Scene Editor, hey?) Thus, I want to know the following?
Is EggNode.getNextChild() sequential or hierarchical? Drawing an analogy to XML, I would ask if this was a SAX method or a DOM method?
Is there a way to immediately convert a NodePath and its attached Node Hierarchy back into EggData, the same same way one can convert EggData to a NodePath?
Why did the programmers of Panda not choose an XML format for EGG Files? XML is much easier to parse.
I saw your example. I am curious to know where the iterChildren() function resides because I don’t see it appear anywhere in the provided documentation. Is it a function that has been removed by any chance?
its a helper function i made. An example of how to make panda3d more pythonic … it would make much more sense to attach it to egg node though. If you look at the source:
def iterChildren(eggNode):
""" iterate all children of a node """
try:
child = eggNode.getFirstChild()
while child:
yield child
child = eggNode.getNextChild()
except:
pass
I saw it now. I think drwr didn't understand my question properly. From your usage, it seems that getnextChild() is hierarchical, meaning that it traverses across all Children of the same level, rather than that it traverses through all Children.
By the way, I notice the use of a "type()" function in your code. Which standard library module does it belong to, or is it in "__builtin__"?
Also, incidentally, would it be a good suggestion to create a standard XML version of EGG Files for the next version of Panda, since that would be easier to work with for beginners; mainly, that there is already extensive support for XML parsing, or Panda3D could implement its own XML parser, on the lines of IrrXML (XML for Irrlicht 3D Engine)? XML is much more flexible after all. And it would work, since EGG Files contain a sort of "model graph" as well, and are not just chunk files.
Lastly, how do you add CollisionNodes (apart from Segments and Rays) to an EggNode Hierarchy?
No egg is here to stay. I don’t like XML and will argue against it. Egg is easy to edit with a plain text editor while XML is not. Python does not use that much xml either. XML is favorite for languages like java/C# not python. I would not mind jason or YAML though.
Also “XML version of EGG” could mean COLLADA which i would like to see due to many tools already using it. I am against another random XML format, XML must die unless its useful!
getnextChild() is NOT hierarchical
IterChildren gets only the children under a given node not the children of the children.
I use XML for alot of my data parsing. Saying that Python doesn’t use much XML is wrong, saying that the programmer didn’t use much XML is right.
Python has inbuilt XML parsers just like 99% of other modern programming languages.
XML is based on a tree structure there are parents and children both can have attributes and content. Content and attributes are in the form of plain text. I don’t know if you realised this (you probably have) but the node structure that Panda3d uses, is a tree structure and can be formatted into XML to with minimal effort.
Two different styles of XML formatting could be used
using attribute style, or content style
import sys
from xml.dom import minidom
#lets say that node.xml is an xml file containing the above code
myXML = minidom.parse("node.xml")
#to access data using the attribute method
for node in myXML.childNodes:
#or - for node in myXML.getElementsByTagName('node'):
x = node.getAttribute('x')
y = node.getAttribute('y')
z = node.getAttribute('z')
h = node.getAttribute('h')
p = node.getAttribute('p')
r = node.getAttribute('r')
print x, y, z, h, p, r
#to access data using the content method
for node in myXML.firstChild.childNodes:
if node.nodeType != minidom.Node.TEXT_NODE:
x = node.getElementsByTagName('x')[0].firstChild.data
y = node.getElementsByTagName('y')[0].firstChild.data
z = node.getElementsByTagName('z')[0].firstChild.data
h = node.getElementsByTagName('h')[0].firstChild.data
p = node.getElementsByTagName('p')[0].firstChild.data
r = node.getElementsByTagName('r')[0].firstChild.data
print x, y, z, h, p, r
I much prefer the attribute method because you don’t have to deal with annoying whitespace.
It’s true, egg format could be wrapped inside XML without too much trouble. Except, of course, for the thousands of egg files that we (and other people) already have. So we’d either have to run all of them through some filtering tool, somehow, or we’d have to make the parser be backward-compatible with existing egg files too.
At the end of the day, though, I suggest following the maxim: if it ain’t broke, don’t fix it. There’s nothing wrong with egg syntax, as it is, and it isn’t difficult to parse. Furthermore, we provide a library that will do all of the parsing for you, but even if you can’t or choose not to use this library, you can write your own parser without much trouble at all (and several have done this).
Replacing the egg syntax with an XML syntax would buy a tiny bit of convenience, but not really a whole lot, and it would be a major pain in the butt to make the transition. There are lots of other things that we could be spending our efforts on in the meantime instead.
I wasn't talking about replacing it. What I meant is: add in 1 more format. So - as I clarified to treeform earlier - we could have BAM, EGG and EML (Egg Markup Language). Then, the same way as we have Bam2Egg and Egg2Bam, we could have Egg2EML and EML2Egg.
By the way, the reason why I suggested EML was because you seem to bee telling me that all the model-manipulation and image-manipulation features in Panda3D are all for offline purposes. SO I thought it would be great to have an online version.
Why replace it by some made up format like EML when we can use COLLADA which is exact same thing but lots of tools have exporters and importers for it.
Right. Egg is an excellent format, there is nothing wrong with it.
If you need XML, I would indeed go for COLLADA. It’s an excellent format as well. One would not need to write extra exporters for it or so, since it is already widely supported by all kinds of modelers.
I’m currently in the process of creating a COLLADA importer, so have patience.
Any XML-based file format will also, almost necessarily, be more suited for offline purposes than for real-time purposes. The only real-time-appropriate format is Bam, and that’s because Bam is specifically designed to hold data in very nearly the same form it is stored internally within Panda. This makes Bam files very fast to load, compared to any other file format, which will always require some conversion step.
On the other hand, these very same close-to-the-metal design decisions make bam files inappropriate for many of the things that egg files (and Collada files) are appropriate for. For instance, operations like computing normals or optimizing character joint hierarchies are difficult to do in bam files, but easy in egg files. Writing external converters to and from other file formats is difficult for bam files, but easy for egg files. Human readability is difficult for bam files, but easy for egg files. Long-term version-independent storage is difficult for bam files, for easy for egg files. The list goes on.
Basically, you have two fundamentally different choices for a file format: make it store data close to the way Panda thinks about models, or make it store data close to the way humans think about models. The first compromise makes the file load fast but hard to work with; the second makes it easy to work with but slow to load. The need for both kinds of file formats is why we have both egg and bam.
I realize that our discussion veered off quite a bit. While the minimap is an important aesthetic feature, it isn't the mainf eature of the program. My main features are editable terrain and placeable 3D objects. I believe the latter isn't that hard to do, so it is the former that is giving me a headache. I am puzzled as to how to obtain the individual vertices of a model to transform. My concept of Editable Terrain requires one to pull and push the actual vertices of the terrain geometry. If I used a set of linked GeomLines and GeomPoints, I could simulate the deformation of terrain, but I wouldn't have planes to put objects on. If I regenerated a polygonal terrain every frame, it would be extremely slow, I believe.
There is of course the PNMImage option - basically editing the heightmap for a GeoMipTerrain. But then, once again you guys have persuaded me that it is a very inefficient way.
SO then, my question is: Is it in Panda3D's capabilities to produce an editable terrain manager?