Jump to content

  •  

New Client


  • This topic is locked This topic is locked
76 replies to this topic

#61 Learner

Learner

    God

  • Administrators
  • 2805 posts

Posted 06 May 2016 - 03:53 AM

Yes, but is there something in those objects where he can automatically determine which one will look backwards? Could it be something as simple as the order of the coordinates in the 2DO are different or how they are placed on the map that's causing different rendering on them?

#62 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 08 May 2016 - 02:07 PM

Ok so, on the matter of the 2do problem, I did an analysis on all the data and determined that the objects that seem to line up correctly are all at angles of either 0, 90, 180 or 270 degrees. Everything outside of those angles seems to be problematic.

Interestingly, even when I rotate those objects, they still don't line up, suggesting that the issue is both rotation and positioning. If we look at how the OL client does rotation, we see

a ) It takes the rotation angle x pi / 180, hence converting a rotation angle in degrees degrees to radians. However, there's no need to do this in Irrlicht as its rotation functions are based on degrees.

b ) It then calculates the sine and cosine of the above value (cos_m and sin_m) to determine the distance each vertex is to be moved

x_move =  x_pos * cos_m + y_pos * sin_m
y_move = y_pos * cos_m - x_pos * sin_m


The above is applied to all the vertices suggesting a rotation around the centre of the object. Herein may lie the problem as Irrlicht rotates around the top left vertex.

#63 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 09 May 2016 - 01:18 AM

Excellent deduction Munt! So is it still convertable? Now I feel bad about spending the last 4 years forgetting all that math I learned lol. It's probably a pretty simple solution...

#64 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 09 May 2016 - 11:51 AM

Yup, i'm determined it will be convertible, however, it's not quite as simple as you'd think. Changing the point of rotation of a mesh seems to require some fairly complex maths. The challenge for me to properly understand that before implementing a coded solution.

However, I should say that i'm progressing on other fronts, particularly implementing a gui for the nascent map editor. I've got as far as incorporating a horizontal menu bar across the top of the window, plus a vertical tool bar.

Posted Image

#65 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 09 May 2016 - 12:06 PM

Nice!

#66 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 10 May 2016 - 03:27 PM

thx kiwi

#67 AlddrA

AlddrA

    Advanced Member

  • Full Member
  • PipPipPip
  • 716 posts
  • LocationCanada

Posted 10 May 2016 - 04:18 PM

Sorry I don't congrats you munt, I know nothinnnnng about doing graphics:/

#68 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 22 May 2016 - 05:40 PM

So although i've not posted an update for a while, i've still been bashing my head against the wall in an effort to fix the annoying artifacts and, finally, seem to have fixed the issue. Hence:

The path now end neatly

Posted Image


The garden has now lost the weird sticking out piece of grass

Posted Image

And the gang plank now faces the correct way

Posted Image

I forget just how many weeks (months even) that i've been working on trying to solve the render issue, so it's a blessed relief to have finally cracked the issue. In the process, i've used matrices, quaternions and every kind of fancy trigonometry. However, in the end, the solution was simply to reverse the z axis of the rotation.

On the assumption that Stardark and others may be fighting with the same issue, here's the code for the 2d object render. Although it's Irrlicht specific, the same general approach should apply to Unity, Orgre and pretty much any other 3d engine that's coded in a C derived language.

void draw_twod_object_list(const char *elm_filename, float tile_size, struct elm_header_type *elm_header){

//create a struct to hold the twod object list
struct twod_object_list_type twod_object_list[MAX_MAP_TWOD_OBJECTS];

//create struct to hold twod file data
struct twod_object_type twod_object;

//read the twod object list from the elm file into the struct
read_twod_object_list(elm_filename, twod_object_list, elm_header);

//draw the twod object list
for(int i=0; i<elm_header->twod_object_count; i++){

//get the twod object file corresponding to the object to be rendered
char twod_filename[FILENAME_LEN]="";
extract_file_name(twod_object_list[i].twod_path_and_filename, twod_filename);

//read the twod object file data into a struct
read_twod_file(twod_filename, &amp;twod_object);

//check we have the texture atlas indicated in the twod object file
if(file_exists(twod_object.texture_filename)==true){

//create a plane mesh for the object
float mesh_width=tile_size/6*x_size*2.0f;
float mesh_height=tile_size/6*y_size*2.0f;
scene::IMesh* twod_mesh=smgr->getGeometryCreator()->createPlaneMesh(
dimension2d<f32>(mesh_width, mesh_height),
dimension2d<u32>(1,1),
NULL,
dimension2d<f32>(1.0f, 1.0f));

//add the mesh to the scene graph
twod_node[i]= smgr->addMeshSceneNode(twod_mesh);

//set the texture for the object to the texture atlas file
twod_node[i]->setMaterialTexture(0, driver->getTexture(twod_object.texture_filename));

//extract the uv parameters for the sub texture
int u_start=twod_object.u_start;
int u_end=twod_object.u_end;
int v_start=twod_object.v_start;
int v_end=twod_object.v_end;
float x_size= twod_object.x_size;
float y_size= twod_object.y_size;

//translate and scale the texture matrix to the sub texture
float u1=(float)u_start/twod_object.file_x_len;
float v1=(float)v_start/twod_object.file_y_len;
twod_node[i]->getMaterial(0).getTextureMatrix(0).setTextureTranslate(u1, v1);
float u2=(float)(u_end-u_start)/twod_object.file_x_len;
float v2=(float)(v_end-v_start)/twod_object.file_y_len;
twod_node[i]->getMaterial(0).getTextureMatrix(0).setTextureScale(u2, v2);

//calculate and set the position of the object on the map
float x_pos=(tile_size*32/192*twod_object_list[i].x_pos*2.0f);
float y_pos=(tile_size*32/192*twod_object_list[i].y_pos*2.0f);
float z_pos=twod_object_list[i].z_pos;
twod_node[i]->setPosition(core::vector3df(x_pos-24.5, z_pos-90, y_pos-24.5));

//rotate the object (reversing the z axis)
float x_rot=twod_object_list[i].x_rot;
float y_rot=twod_object_list[i].y_rot;
float z_rot=twod_object_list[i].z_rot;
twod_node[i]->setRotation(vector3df(x_rot, 360-z_rot, y_rot));

//scale the object to the correct size
twod_node[i]->setScale(core::vector3df(1.1, 0.75, 1));
//implement back face culling to reduce GPU load
twod_node[i]->setMaterialFlag(video::EMF_BACK_FACE_CULLING, false);

//set the alpha of the texture so that texture boundaries are hidden
twod_node[i]->setMaterialType(EMT_TRANSPARENT_ALPHA_CHANNEL);
twod_node[i]->getMaterial(0).MaterialTypeParam = 0.9f;
}
else {
printf("can't find file [%s] specified in 2d0 file %s\n", twod_object.texture_filename, twod_filename);
exit(1);
}
}
}

So what's next ????

Well some of the object scaling could do with some tweaking but, other than that, i'm fairly happy to forget about the finer points of rendering elm files (at least for a bit) and focus on continuing to develop the required map editor functionality. My next goal is to develop the mesh selection and drag/drop mechanisms.

View PostAlddrA, on 10 May 2016 - 04:18 PM, said:

Sorry I don't congrats you munt, I know nothinnnnng about doing graphics:/

Lol. Not sure if I understand much more than you. The learning curve for some of this stuff has been mightily steep and i'm having trouble grasping some of the issues myself. I'm therefore symapthetic with anyone who reads this stuff and thinks wtf is he rattling on about. However, it's nice just to have peeps just posting their encouragement. :)

#69 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 22 May 2016 - 08:34 PM

Awesome work Munt. I knew it was simple. Sorry it took so long to figure out. I'm  very proud of you xD

I appreciate you taking the time and frustration to figure all this out. Fantastic job.

#70 AlddrA

AlddrA

    Advanced Member

  • Full Member
  • PipPipPip
  • 716 posts
  • LocationCanada

Posted 23 May 2016 - 04:38 AM

As Kiwi says......awesome work!!.   WOW you are fantastic to figure it all out.....what a brain.   No wonder many of us mortals cannot understand you.   Thank you for taking this effort to improve the map editor.  You're the best :wub:

#71 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 24 May 2016 - 06:13 PM

View Postthemuntdregger, on 02 May 2016 - 03:47 PM, said:

So i've started to work on coding the basic functionality for a map editor. What i'm going to do is to have separate editor modes for tiles, 2d objects and 3d objects. In all modes it will be necessary to select a specific mesh for editing, hence, i've been working on the mechanism to do that.

So i've completed the code that detects what mesh the cursor is over (it can even detect the specific triangle in the mesh). Atm, the detected mesh is rendered in wireframe (as per Stardarks original Unity code). Only problem is that this isn't a good way to deal with tile editing as the required functionality requires the user to see changes in texture. I've therefore got to find a better way to highlight the selected tile, either by outlining or, by increasing specular luminosity.

So i've managed to solve the above by superimposing the wireframe over the texture so that it looks like:

Posted Image

Plus the wireframe moves as you move the cursor which looks pretty cool and seems a good way to select objects for editing or moving. However, using the cursor is this way locks it to the viewport in a way that prevents access to the gui. I've therefore implemented a 'listener' which detects key presses and which allows you to enter or escape the edit/move mode by hitting a particular key.

Dunno if i'm going to stick with this mechanism as (imho) it's clumsy. An alternative (possibly better) way is to move the camera position using keys so that the cursor can be moved independently to the camera view. That then avoids locking the cursor and provides flexibility for it to point at either map or gui objects.

#72 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 24 May 2016 - 06:53 PM

If I understand what you're talking about (I could be way off), it looks like a highlight over an object before you click on it so you can see what you're going to click on? In that case, it seems like the best way to implement that would be to allow a special "select/highlight" key or UI button. I have no idea how it works with the UI lock you're talking about though. I'm probably too dumb to understand without further explanation of how it all works lol.

#73 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 25 May 2016 - 11:58 AM

View PostKiwi06, on 24 May 2016 - 06:53 PM, said:

If I understand what you're talking about (I could be way off), it looks like a highlight over an object before you click on it so you can see what you're going to click on? In that case, it seems like the best way to implement that would be to allow a special "select/highlight" key or UI button. I have no idea how it works with the UI lock you're talking about though. I'm probably too dumb to understand without further explanation of how it all works lol.

Nope, you've understood it entirely correctly. The cursor lock occurs because, the current camera view keeps the cursor in the centre of the screen and moves the world around it (what is referred to as a 'first person shooter' type view). As a result, you can't move the cursor to the edge of the screen in order to activate gui components.

What I want t implement is a camera view in which the world is moved by keys and the cursor is then able to roam to all parts of the screen (kind of like the current OL client works). Whilst it sounds fairly simple to achieve, in practice, it's far more complex. This is because the fps view is handled directly by the 3d engine, whereas what i'm proposing needs to be coded separately.

#74 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 25 May 2016 - 07:20 PM

Yikes. Learning is hard. I believe in you munt!

#75 themuntdregger

themuntdregger

    Official Troll

  • Full Member
  • PipPipPip
  • 1001 posts
  • LocationBehind you

Posted 28 July 2016 - 01:44 AM

So i'm embarrassed that i've not posted an update since May. Tbh, I was a sick bunny for a while but am getting pretty tired of that excuse. Latterly, i've been wrestling with transferring my dev environment from the old lappy to the new sooper dooper one. That's now mostly completed and everything is now set for me to pick up where I left off and start seriously hacking the shit out of things.

In the interim (as a side project) I created a new compile environment for the existing ol codebase which bypasses the shitty makefile and allows me greater control of the compile process. Of course, being an arse, I turn on every error warning known to man and create a shed load of marvelous new compiler whinings that the shitty makefile covers up. Tbf, whilst I describe the make file as shitty, it's actually rather clever. My personal beef is that it's complex and unnecessarily obfuscated by an appalling lack of any kind of useful code documentation. This is fairly typical of stuff written by C geeks who like to write their shit so as only the truly worthy can work out wtf is going on. Myself, I come from an entirely different tradition which believes that even 'hello world' needs to be documented so as even a goldfish will grasp what's going on.

Anyhow, a more prozaic reason for mucking about with the old client codebase was the need to diagnose what has turned out to be a lingering and persistent problem, ie accurately rendering the existing maps under a new 3d engine. Back in May, I thought i'd cracked the issue, however, i've recently identified another rendering errors. Tbf, it's not just my code on which this error shows up, but also on Stardark's Unity project, hence, this is an issue that needs to be solved for both projects. Were it not for the above, i'd be cracking on with building in functionality to the Irrlicht based map editor.

I'd really like to start posting some code so as other interested parties can see how far i've got and maybe add some of their own stoofz. For ease, i'll prolly post on Github.

#76 Kiwi06

Kiwi06

    Advanced Member

  • Full Member
  • PipPipPip
  • 544 posts
  • LocationMissouri, USA

Posted 28 July 2016 - 06:53 AM

Great to hear Munt :)

I'm excited to see what else you've got up your sleeve. Any info on the current problem? Not that I am any help, but I do like reading about your progress and we peons like to watch the elegant splendor of each text wall you put up.

#77 AlddrA

AlddrA

    Advanced Member

  • Full Member
  • PipPipPip
  • 716 posts
  • LocationCanada

Posted 28 July 2016 - 09:00 AM

Well said Kiwi \o/.    Yes we do munt, don't stop!! :wub: :lol: :D




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users