This site uses cookies! Learn More

This site uses cookies!

armedunity.com uses cookies to improve user experience.

By continuing to use this site, you agree to allow us to store cookies on your computer.

OcularCash

ADG
  • Content count

    3,203
  • Joined

  • Last visited

Community Reputation

782 Excellent

About OcularCash

  • Rank
    Team Member
  • Birthday 04/29/1985

Profile Information

  • Gender
    Not Telling
  • Location:
    Springfield Missouri USA
  • Interests
    Javascript, 3d Modeling, Foley Recording, Photography
  1. nvm, looks like it's only rendering half the models in the scene correctly. Last night I used a basic cube anchored to left hand coordinates to get it how it's supposed to be. But this morning I tried an entire scene and it seems some models are flipped on the z (as they should be) and some are flipped on the y for some weird reason. Before adding the z calculations everything rendered together, just on a left hand coordinate system. So I'm guessing I messed up somewhere somehow. I'm going to have to step through the shader code later and see which line it is that is flipping some of the models upside down. lighting is working great tho so I guess that's a plus lol edit: fixed. I inversed [+] the z positional coordinates but I forgot to inverse [+] the x rotational matrix. I'll post it later tonight or tomorrow
  2. Merged. Got it to render as it should. Since OpenGL uses left hand coordinates and unity uses right hand with inversed (positive) x (+x, +y, +z) I had to flip the camera, inverse the x transformation (+x) and negate the view matrix (-x) to flip x world coordinates. The model then get flipped inside out once I inverse the x (+x) the vertice positions so I had to cull the front face instead of the back. A lot of fiddling but it's working... hopefully for good. We will see once I add light calculations edit: Even better, just negated the transformations z and inversed (+z) the view matrix. Then inverted the z in the vertex shader and culled the front face. Now I don't have to flip the camera
  3. Merged. If the mesh isn't triangulated or there were no included uvs or normals it will throw that error. Basically just saying the format of the mesh is not what's it's expecting
  4. Ya, I'll get around to that eventually. Some of the code itself has to be changed as the code I'm using to to import only works within the ide at the moment. It's not that much more that has to be added to compile as a standalone but I haven't had the need to add it yet. the rest of the stuff is things like compiling to a jar and turning it into an executable, then adding the resources and recompiling to hide them. But I will write up a compiling instructional once I get to that point. Right now I want to focus get the core engine to where it needs to be
  5. v0.01b will be available soon. Having some issues getting the right view matrix and/or transformation matrix to match unitys. Everything is working, just have debug the matrices being sent to the shader to get the proper projection axis. Once the matrices are fixed, I will post it. 0.001b will include unity scene exporting for gameobjects, transform, cameras, mesh renderer / filter and exporting if used textures, materials and mesh. Just hit the export button in unity, select the res path and click play in DevEngine, simple as that
  6. Looks like it should work from what I've read about it. Not sure why that's happening
  7. Sounds good. Probably will tomorrow. Doing birthdays for 2 of my sons today
  8. It's a story book game... the kingdoms are split up into different storybook lands. 1 kingdom may be a Dracula type kingdom with zombies (from graves, not the new age) with vampires and werewolves and another kingdom maybe like Hansel and Gretal with candy opponents and witches. So each kingdom is themed. The goal is collect keys from each boss of each kingdom to open the door back to reality. The Magnificent Mind of Delirious Devon and the Hunt for Home... is what I'm thinking the name will be. Fits the story of a boy trapped in a delusional world making his way back to reality. Trapped in an open world environment that was said to be fairy tales edit: might change it from collecting keys to collecting pieces of his mind
  9. My character models are very simple and easy to make. Every model uses the same base mesh and I just extrude things here and there and change the skin. Here is the zombie that just uses extrusions based on the main character Zombie.zip
  10. Looks good. My kind of art style. Not really feeling the character poly tho. I like the skin but the boxy character is throwing it off, I guess just bc it's so overused. Big reason why I'm personally doing a melon head character bc it hasn't been used too much since the 90's edit: and by the way, great thinking on the dark skinned character, don't really see that much
  11. Thanks erarnitox. Just finished scene file importing. It's pretty basic but it does the job for the moment. It will be more complex in the future initializing new classes ON classes and blahdy blahdy blah, but don't really need it just yet. Here is what it currently looks like: &TestObject 0,0,0 0,0,0 1,1,1 >engine/Camera >engine/MeshRenderer/Flowers,Default >game/Test &TestObject2 1,0,0 0,0,0 1,1,1 >engine/MeshRenderer/Cube,Default "&" Tells me the name of the gameobject to be instantiated in the scene. The first 3 lines after tells me the position, rotation and scale of the transform. ">" Tells me that there is a component attached. "engine/camera" Tells me the script I want to add is in the engine package and it's name is camera. "engine/MeshRenderer/Cube,Default" Tells me that I should add a MeshRenderer found in the engine package with the a mesh named "Cube" and a material named "Default". At this current moment, The only way to create a scene file and edit it is by hand and typing it up. Once I get around to it, I will make a scene exporter for Unity so you can use Unity as a scene builder and export the scene file and run it in DevEngine. There will also be an editor in DevEngine but it won't be at the scale of Unity, basically just to add components to objects and change there variables and so on. Here is the importer in Java so you can see how it loads in code: /////Import a scene save file from disk public static void ImportScene(String filePath, String fileName) { //Create an empty file reader FileReader fr = null; //Try to open the file at the given path try { fr = new FileReader(new File(filePath)); } //If the path doesn't exist, print and error and the stack trace catch(FileNotFoundException e) { System.err.println("Couldn't load file"); e.printStackTrace(); } //Create a new buffered reader and initialize a temp string BufferedReader reader = new BufferedReader(fr); String line; //Try to parse try { //Read the first line and create a temp GameObject variable line = reader.readLine(); GameObject go; //If the line at this moment is an object if(line.startsWith("&")) { //While the line at this moment is an object while(line.startsWith("&")) { //Set a new GameObject in the temp variable and read in it's transformations go = new GameObject(line.replaceAll("&", "")); String[] position = reader.readLine().split(","); String[] rotation = reader.readLine().split(","); String[] scale = reader.readLine().split(","); //Parse and set the transformations on the GameObject go.transform.position.Set(Float.parseFloat(position[0]), Float.parseFloat(position[1]), Float.parseFloat(position[2])); go.transform.rotation.Set(Float.parseFloat(rotation[0]), Float.parseFloat(rotation[1]), Float.parseFloat(rotation[2])); go.transform.scale.Set(Float.parseFloat(scale[0]), Float.parseFloat(scale[1]), Float.parseFloat(scale[2])); //Trim the spaces out of the beginning of the line if any line = reader.readLine().trim(); //If the line is component information if(line.startsWith(">")) { //While the line is component information while(line.startsWith(">") && go != null) { //Parse the string and add the component to the current GameObject String[] path = line.replaceAll(">", "").split("/"); go.AddComponent(path[0], path[1]); //If the component is a MeshRenderer if(path[1].equals("MeshRenderer")) { //Get the added MeshRenderer and parse the variables out MeshRenderer mR = (MeshRenderer) go.GetComponent("MeshRenderer"); String[] visuals = path[2].split(","); //If the MeshRenderer is not null (Just a safety check. Should never be null at this point) if(mR != null) { //If the mesh for this renderer is not supposed to be null, find and attach it if(!visuals[0].equals("null")) { mR.mesh(Mesh.Find(visuals[0])); } //If the material for this renderer is not supposed to be null, find and attach it if(!visuals[1].equals("null")) { mR.material = Material.Find(visuals[1]); } } } //Read in the next line line = reader.readLine(); //If the line is not null, trim out the spaces like before if(line != null) { line = line.trim(); } //If it is not, break out else break; } } //If the line is null, break out if(line == null) break; } } //Close the reader reader.close(); } //If the file isn't parsing properly catch (IOException e) { //Print the stack trace e.printStackTrace(); } } Pretty simple to understand but like I said, at the moment, it's still quite basic. I've also go most of the primitives class done, so primitives are generated by code on start and stored into memory. As you can see in the scene file, the mesh "Cube" is actually using the Cube primitive that is now built in. The gui is still barebones and non operational tho. I will not begin GUI until I finish the PostProcessing Pipeline because the gui will participate at the end inside of an fbo (Frame Buffer Object, same buffer type as what postprocessing uses). Edit: Finished adding loading variables in custom game scripts. You will need to add a function like this to your script: public void Set(String[] v){} Inside this function, you will just need to parse it and add to the corresponding variables. The reason this system does it like this is that unlike normal game engines, I am removing 99% of all reflection calls and setting variables in normal engines indeed use reflection to get and set variables that contain custom (public) properties. My engine will ofcourse not, but will need to add the Get and Set function and tell the parser which variables you want to save and load for a specific class and parse the variable information to set them
  12. ive actually stress tested ongui with texture guis (1drawcall per GUI) that will give you a good idea about approx drawcall frame dropping. This is testing strictly draw calls, you also have to factor in vert count when dealing with drawcalls with mesh. This test test was done on an average pc. As you can see, fps isn't affected much by thousands of drawcalls with mesh drawcalls, drawcalls don't matter much, it's the very count that kills you the most. I can bog a decent pc with 10 draw calls with the right mesh
  13. C++ is great, but only maybe a total of 5 people on this forum knows the basics of it, let alone advanced knowledge. C++ is actually my first language, but no sense in making an engine no one on the forum could use. c# on the other hand, nearly everyone here knows. The problem with c# is it's like the bastard child of c. Which means a long time ago it was a great language and there was large amounts of resources available and wrappers. Nowadays, not so much. C++ overshadows c# so much, not because it's better but because it was it was made the "college language", that dx is literally dead on newer windows for it and they're OpenGL is a huge hunk of outdated scrapmetal. Trust me, I looked for quite some time, I wanted to do a c# version for the community but I want to provide a performance upgrade, not a downgrade. java was the best alternative to c# for both me and to release. Even tho it's literally identical c# so much that if I posted code here right now no one would know the difference unless I told them, Java is outside of the c family and there OpenGL api, mainly lwjgl in my personal opinion, is some of the best out there. And since the release of mine craft, Java apis have been getting massive love by API developers. when it comes down to making something as large as unity and faster than unity, yes we can can make it faster (unity is actually slow as snails), but user friendly and sack wise, 2 men cannot achieve that. Also, besides myself, and I'm not aware of any other forum member that has tackled making a 3D game engine on the forum and making a game engine is a lot different than making a game.
  14. Updated
  15. If your still having troubles when I get home, I'll add to the read me file